Was braucht eine guter IDE-Editor?

mikey

VA für VS? Was ist das? Visual Assist? Wie kann ich das anstellen?

Maxi

das kann man nicht anstellen. Muss man kaufen. bei wholetomato.com oder man besorgt es sich auf.... naja.. auf anderen Wegen.

Artchi

mikey schrieb:

VA für VS? Was ist das? Visual Assist? Wie kann ich das anstellen?

runter laden und installieren?

mikey

Ich dachte, es ist in VS intergriert. Aber danke für den Hinweis.

rüdiger

* Syntax-Highlight am besten Kontext sensitiv (also eigene Typen und typedefs werden auch gehighlightet) und Matchende-Klammer-Highlight
* Sehr Gute Scripting Funktionen, um sich schnell fehlende Sachen einbauen zu können
* Compilieren/Fehleranzeige eingebaut
* Tolle funktionen (als keymap eben) ala "Springe zur matchenden Klammer", "springe zum nächsten/vorherigen Wort", "indent-region" etc.
* Unterstützung für Source Code Management Werkzeuge
* Bei dynamischen Programmiersprachen auch direkt eine Einbindung des Interpreters/JIT.

Sehr nützlich:
* Syntax-Highlight und spezieller Support für viele Programmiersprachen/Formate
* Aktive "Community"

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Compiler- und IDE-Forum verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

tfa

doch schrieb:

spaces statt tabs sind behindert:
man braucht länger um über die selbigen zu navigieren und
wenn man im team arbeitet hat jeder vielleich gern eine andere einrückung. mit spaces geht das nicht, bei tabs kann jeder in seinem editor einfahc einstellen wie breit ein tab sein soll fertig.

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.

Maxi schrieb:

Was ich gut finde ist, wenn mehr als nur Intellisense drin ist. Also das auch Wörter die man grad getippt hat wieder vervollständigt werden.

Besser ist es, wenn der Kontext beachtet wird. Wenn ich einen Funktionsparameter übergeben will sollen z.B. nur die Variablen die auch vom Typ her passen vorgeschlagen werden.

Artchi

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.

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.

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.

Artchi

rüdiger schrieb:

* Syntax-Highlight am besten Kontext sensitiv (also eigene Typen und typedefs werden auch gehighlightet) und Matchende-Klammer-Highlight
* Sehr Gute Scripting Funktionen, um sich schnell fehlende Sachen einbauen zu können
* Compilieren/Fehleranzeige eingebaut
* Tolle funktionen (als keymap eben) ala "Springe zur matchenden Klammer", "springe zum nächsten/vorherigen Wort", "indent-region" etc.
* Unterstützung für Source Code Management Werkzeuge
* Bei dynamischen Programmiersprachen auch direkt eine Einbindung des Interpreters/JIT.

Sehr nützlich:
* Syntax-Highlight und spezieller Support für viele Programmiersprachen/Formate
* Aktive "Community"

Hem, hat eigentlich VS alles... oder soll das jetzt nur eine Zusammenfassung aus diesem Thread sein?

rüdiger

Artchi schrieb:

rüdiger schrieb:

* Syntax-Highlight am besten Kontext sensitiv (also eigene Typen und typedefs werden auch gehighlightet) und Matchende-Klammer-Highlight
* Sehr Gute Scripting Funktionen, um sich schnell fehlende Sachen einbauen zu können
* Compilieren/Fehleranzeige eingebaut
* Tolle funktionen (als keymap eben) ala "Springe zur matchenden Klammer", "springe zum nächsten/vorherigen Wort", "indent-region" etc.
* Unterstützung für Source Code Management Werkzeuge
* Bei dynamischen Programmiersprachen auch direkt eine Einbindung des Interpreters/JIT.

Sehr nützlich:
* Syntax-Highlight und spezieller Support für viele Programmiersprachen/Formate
* Aktive "Community"

Hem, hat eigentlich VS alles... oder soll das jetzt nur eine Zusammenfassung aus diesem Thread sein?

Seit wann geht es in dem Thread um VS? (Ganz zu schweigen davon, das ich nicht weiß ob VS das wirklich alles kann...)

Artchi

Geht es nicht um das Sammeln von guten IDE-Funktionen? Und meine Anmerkung/Feststellung war einfach nur, das VS das kann. Nicht mehr und nicht weniger. Schlimm?

Blue-Tiger

tfa schrieb:

Blue-Tiger schrieb:

* Convert Spaces to Tabs

Wohl eher umgekehrt. Tabs haben im Quelltext nichts zu suchen.

Darueber kann man ewig flamen, ich selber kanns nicht ausstehen wenn Code mit Spaces eingerueckt ist... deswegen brauch ich eine IDE, die da konvertieren kann.

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.