Was braucht eine guter IDE-Editor?

tfa

Artchi schrieb:

tfa schrieb:

Das ist Unsinn. In meinem Editor navigier ich wort- oder blockweise, egal ob Spaces oder Tabs verwendet werden. Die Tab-Größe zu verstellen und zu glauben, der Quelltext würde dann noch gut aussehen, funktioniert in der Praxis leider auch nicht. Besonders wenn Tabs und Spaces gemischt auftreten, was man natürlich nie verhindern kann. Ich habe vor einiger Zeit mal Richtlinien für ein Projekt definieren müssen und hierzu etliche Coding-Standards von Open-Source-Projekten, Firmen und Institutionen studiert. Fast alle haben Tabs verboten.

Tabs wurde damals hauptsächlich verboten, weil die Compiler/Interpreter das nicht verstanden haben.

Wer redet von "damals"? Ich meine aktuelle Coding-Standards.

Artchi schrieb:

Ansonst: ich bevorzuge Tabs, weil ich WILL mir meine Tab-Breite selbst einstellen. In unserem Java-Projekt ist z.B. Tab nicht verboten. Und darüber bin ich froh.

Ich muss recht häufig Quelltext von anderen Leuten lesen und ärgere mich jedes mal über durch Tabs verursachte unsinnige Einrückungen. Wenn man auf dem Standpunkt steht "ICH WILL aber mein eigenes Süppchen kochen", müssen andere eben darunter leiden. Wenn Du und das Team damit leben können, OK.

Artchi schrieb:

Ob es aber am Ende ein Projekt verbietet, ist jedem Projekt selbst überlassen. Nur zu sagen "Die anderen habens auch verboten" halte ich für ein schlechtes Argument.

Das war nicht als primäres Argument gemeint, sondern vielmehr als Beleg, dass es eine verbreitete Auffassung ist.

Bashar

Artchi schrieb:

Tabs wurde damals hauptsächlich verboten, weil die Compiler/Interpreter das nicht verstanden haben.

Kannst du das belegen?

Ben04

tfa schrieb:

Ich muss recht häufig Quelltext von anderen Leuten lesen und ärgere mich jedes mal über durch Tabs verursachte unsinnige Einrückungen. Wenn man auf dem Standpunkt steht "ICH WILL aber mein eigenes Süppchen kochen", müssen andere eben darunter leiden. Wenn Du und das Team damit leben können, OK.

Wer mit Tabs umgehen kann dessen Code wird auch noch sehr gut leserlich in einem anderen Editor mit anderer Tab-Länge sein. In Kommentaren haben die nämlich nichts zu suchen.

Falls die dich wirklich sooo sehr stören dann konvertiere sie einfach. Tabs raushauen ist einfach. Der andere Weg nicht ganz so einfach.

Tabs wurde damals hauptsächlich verboten, weil die Compiler/Interpreter das nicht verstanden haben.

Kannst du das belegen?

Wenn man bedenkt, dass Borland mal C Compiler gebaut hat die eine leere Zeile am Ende brauchten (und nicht bloß darauf hinwiesen) dann halte ich die Aussage für sehr realistisch.

Artchi

Bashar schrieb:

Artchi schrieb:

Tabs wurde damals hauptsächlich verboten, weil die Compiler/Interpreter das nicht verstanden haben.

Kannst du das belegen?

Ehm, ein Beispiel:

http://www.informatik.uni-kiel.de/~klh/DP04/ schrieb:

Eingabe von Programmtexten
Achten Sie bei der Eingabe von Curry-Programmen darauf, keine Tabulatoren zu verwenden, sondern die Einrückungen nur durch Leerzeichen zu erreichen. Der Parser von PAKCS kommt mit Tabulatoren nicht zurecht. Wenn Sie aus Versehen doch einen Tabulator verwenden, wird PAKCS einen Syntaxerror melden oder ungefähr folgende Fehlermeldung ausgeben:

Lexical error at line 16, column 8. Encountered: "\t" (9), after : ""

Was an einer Tab-Einrückung schlechter sein soll, als an einer mit Space verstehe ich aber nicht. Ich kann auch mit Space eine Formatierung versauen:

void foo(int &i)
{
  if( i == 2)
                 &i = 100;
         else
     &i = 200;            
}

Habe kein einziges mal Tab benutzt.... also, schon sehr merkwürdig das Anti-Tab-Argument.

Gast++

Hab grade ein deja-vu...

Gestern gab's eine Frage nach Sprach-Features im "Rund-um..." Subforum.
Heute hier eine Frage zu IDE-Features.

Beide von unregs; beide ganz offen formuliert, beide ähnlich im Stil...

Seltsam, findet Ihr nicht?

Bashar

Ben04 schrieb:

Tabs wurde damals hauptsächlich verboten, weil die Compiler/Interpreter das nicht verstanden haben.

Kannst du das belegen?

Wenn man bedenkt, dass Borland mal C Compiler gebaut hat die eine leere Zeile am Ende brauchten (und nicht bloß darauf hinwiesen) dann halte ich die Aussage für sehr realistisch.

Das ist was anderes. Der C-Standard fordert explizit, dass Quelldateien mit einem Newline enden: "A source file that is not empty shall end in a new-line character, ...".

Artchi schrieb:

http://www.informatik.uni-kiel.de/~klh/DP04/

Das ist aber offensichtlich keine technische Limitierung, sondern wurde entweder übersehen, oder Tab hat eine spezielle syntaktische Bedeutung, wie beispielsweise in Makefiles. Als generellen Beleg, dass es historische Gründe gegen die Einrückung mit Tabs gibt, würde ich das nicht werten.

Gast++ schrieb:

Hab grade ein deja-vu...

Gestern gab's eine Frage nach Sprach-Features im "Rund-um..." Subforum.
Heute hier eine Frage zu IDE-Features.

Beide von unregs; beide ganz offen formuliert, beide ähnlich im Stil...

Seltsam, findet Ihr nicht?

Am besten wir machen ne Fallstudie dazu.

Gast++

KennerDerSituation schrieb:

Gast++ schrieb:

Hab grade ein deja-vu...

Gestern gab's eine Frage nach Sprach-Features im "Rund-um..." Subforum.
Heute hier eine Frage zu IDE-Features.

Beide von unregs; beide ganz offen formuliert, beide ähnlich im Stil...

Seltsam, findet Ihr nicht?

Am besten wir machen ne Fallstudie dazu.

Q.E.D.

tfa

Artchi schrieb:

Was an einer Tab-Einrückung schlechter sein soll, als an einer mit Space verstehe ich aber nicht. Ich kann auch mit Space eine Formatierung versauen:
void foo(int &i)
{
  if( i == 2)
                 &i = 100;
         else
     &i = 200;            
}
Habe kein einziges mal Tab benutzt.... also, schon sehr merkwürdig das Anti-Tab-Argument.

Hm, Argumentation durch Sich-Dumm-Stellen. Auch nicht schlecht.

audacia

Am wichtigsten finde ich Zeilennummern, Code Insight und Parameter Insight, Paren-Highlighting, viele nützliche Hotkeys (besonders für Seitenwechsel, Ein- und Ausrückungen), Tooltips und eine Strukturübersicht, in der Klassen, Funktionen, Makros in der aktuellen Quelltextdatei angezeigt werden.
Auch auf synchrones Bearbeiten verzichte ich mittlerweile nur ungern.

In IDEs zu einfacher zu parsenden Sprachen wie C#, Java und Delphi findet man zuweilen auch nützliche Features wie eine Fehleranzeige im Quelltext im Stil der Word-Rechtschreibprüfung. JBuilder ging sogar noch weiter: bei unbekannten Bezeichnern bot der Editor an Ort und Stelle an, das nötige Package zu suchen und zu importieren, mittels Refactoring eine entsprechende Variable zu erzeugen o.ä.; warf eine Funktion eine nicht abgefangene Exception, erzeugte er auf Wunsch automatisch den nötigen try-catch-Block um den Aufruf herum etc. Für C++ suchte ich so etwas bisher vergeblich.

Ganz praktisch fand ich in JBuilder (und C++BuilderX) auch Scope Insight, das am oberen Editorrand die Funktionssignatur anzeigte, wenn sie außerhalb des Editorfensters war. Auch kolorierte JBuilder Bezeichner je nach Art (statisch, überschrieben, veraltet, Membervariablen, nicht verwendete Funktionen und Variablen).
Ach übrigens, JBuilder konnte je nach Wunsch Tabs in Spaces umwandeln oder umgekehrt. Damit ist dann fast jeder zufriedengestellt

Bis dieser Komfort auch für C++ verfügbar ist, muß wohl noch einige Zeit vergehen