Delphi Option für "Blockmarkierung um Befehle" gesucht

[himitsu]

Zitat von Jasocul:

Kann man ohne Einrückungen programmieren?

Laut vielen Posts von Anfängern, die nicht weiterkommen, aber wo man das immer wieder sieht.

Scheinbar Ja?

[freimatz]

Ergo: man kann ohne Einrückungen programmieren kommt aber nicht weiter und/oder bleibt Anfänger

[Jumpy]

Zitat von freimatz:

Ergo: man kann ohne Einrückungen programmieren kommt aber nicht weiter und/oder bleibt Anfänger

Es sei denn man benutzt Python, da sollen die Einrückungen ja wichtig sein

[himitsu]

Joar, dort muß man und in Delphi kann man, wenn man die Verschachtelungen sehen möchte, auch ohne kunterbunte Linien.


Aber was musste man rauchen, um auf die Idee zu kommen, unsichtbare Zeichen zur Steuerung des Programmflusses zu benutzen?
Da kann man ja gleich zu Whitespace überlaufen und harakiri begehen.
Obwohl, abgucken oder Ausdrucken is da nich, um Code zu klauen. 🙈

[Rollo62]

Zitat von Jumpy:

Zitat von freimatz:

Ergo: man kann ohne Einrückungen programmieren kommt aber nicht weiter und/oder bleibt Anfänger

Es sei denn man benutzt Python, da sollen die Einrückungen ja wichtig sein

Ich bin jetzt (noch) kein Python-Experte, werde mich demnächst aber mit Python4D beschäftigen.
Ich verstehe es so dass dort Einrückungen den Scope-Wechsel vorgeben, aber eben NICHT NUR die Whitespaces.
Denn das könnte wohl an vielen Stellen problematisch werden.
Deshalb ist meine Vermutung Python nutzt "CRLF plus Einrrückung" für den Scope-Wechsel,
weil es anders schlecht funktionieren würde, wenn auch Space irgendwo im Text was einrückt.

Liege ich damit wohl richtig, oder nicht ?

Das Python-System macht es wohl auch schwieriger längere Zeilen umzubrechen, wenn dort nicht der Scope gewahrt wird, oder nicht ?

[freimatz]

Du wagst es hier von Python zu schreiben? Eine nicht typsichere Sprache?
Ist aber eh inzwischen Off-Topic, hier sollte es um die "Die Delphi-IDE" gehen.

[jaenicke]

Zitat von himitsu:

Aber was musste man rauchen, um auf die Idee zu kommen, unsichtbare Zeichen zur Steuerung des Programmflusses zu benutzen? 🙈

Ist zwar off topic, aber auch das ist gültiger Code in Delphi:



Da ich den Code hier nicht posten kann, liegt er im Anhang. Das ist echt fies, wenn jemand das hinter einen Variablennamen schreibt und man sich dann wundert warum das nicht mehr kompiliert, wenn man bei der Deklaration das Plenken entfernt... (sprich die vermeintlich überflüssigen Leerzeichen)

[himitsu]

Menno, du unsichtbare Variable daffst doch nicht verragen.
Hatte ich vor 'ner Weile auch mal probiert (wäre bestimmt witzig als "billiger" Kopierschutz in OpenSourceCode), genauso wie Smilies und Anderes als Bezeichner.

Aber hier ist es auch nichts, was man wirklich ständig benutzen kann und was sich einfach/schnell eingeben lässt, so wie eben Leerzeichen oder Tabulatoren.
const
    ☑ = True;
    ☒ = False;

function ☺: Boolean;
begin
    ☺ := ☑;
end;

[dummzeuch]

Zitat von himitsu:

Aber hier ist es auch nichts, was man wirklich ständig benutzen kann und was sich einfach/schnell eingeben lässt, so wie eben Leerzeichen oder Tabulatoren.
const
* * ☑ = True;
* * ☒ = False;

function 😁: Boolean;
begin
* * 😁 := ☑;
end;

"Invalid character in input file" (für den Smiley)

[himitsu]

[Edit] Mist, ich muß die "alten" Smilies mal suchen.
Hast Recht, die neuen Smilies sind leider nicht nutzbar.
Bin mir nicht sicher ob die da die Prüfung geändert haben (mir war so, als wenn Puncturation und Whitespace keine gültigen Bezeichner ergeben, aber vielleicht ist es auch als nur "Alphanumerisch" definiert)
[Edit2] OK, der neue Smilieblock liegt über #$FFFF ... maximal 2-Byte UTF-16 ohne Erweiterungen nimmt der Compiler.
Hab's oben ersetzt.

Seit 12 Jahren geht Vieles, ab Delphi 2009,
auch je ein chinesisches Zeichen pro Variable/Typ/Funktion ... spart ungemein viel Speicherplatz.



[back to topic]
Muß mal gucken ... war es Delphi oder CnPack ...
Irgendwo konnte man auch einschalten, dass die Striche nur bei der aktuellen Funktion sind.
So wird man wenigstens nicht so extrem davon erschlagen, wenn man es unbedingt braucht.