Visual Studio. Tabs vs. Spaces Problematik

Herrmann

Hier bei uns werden 4 Spaces zum Einrücken verwendet. Früher hab ich privat 2 Spaces verwendet, nach heutigem Empfinden macht das den Code viel unleserlicher.
Zusätzlich bekommt jeder von SVN eine Fehlermeldung beim Commiten wenn Tabs im Code auftauchen. Zusätzlich werden Umbrüche automatisch in Unix-Umbrüche umgewandelt und Spaces am Zeilenende entfernt.

volkard

Herrmann schrieb:

Hier bei uns werden 4 Spaces zum Einrücken verwendet. Früher hab ich privat 2 Spaces verwendet, nach heutigem Empfinden macht das den Code viel unleserlicher.
Zusätzlich bekommt jeder von SVN eine Fehlermeldung beim Commiten wenn Tabs im Code auftauchen. Zusätzlich werden Umbrüche automatisch in Unix-Umbrüche umgewandelt und Spaces am Zeilenende entfernt.

Je schlechter die Lösung, desto mehr Gewalt braucht man, um sie durchzusetzen.

Ich find die Idee nicht schlecht "unsichtbare Fallen" automatisch rauszuschmeissen. Weil es gibt Editoren die zum Beispiel Leerzeichen am Ende der Zeile entfernen, wenn du nun die Dinger aber im Repo hast kriegst du deswegen einen Diff.

Also hallo nochmal,

Ich habe nun auch in VS2008 versucht auf Spaces umzustellen und es ist Smart bei "Auto Intend" an, aber wenn ich nun TAB drücke um 4 Spaces einzufügen und danach BACKSPACE um die 4 Spaces wieder rückgängig zu machen, entfernt er trotzdem nur 1 Space

Was muss ich denn noch umstellen? bitte helft mir.

knivil

Badestrand schrieb:

Echt? Welcher Editor macht das denn?

Es ist vielleicht nicht exakt, das was dort beschrieben ist: Drucke ich Enter, so ist mein Cursor ordentlich eingerueckt.

Badestrand

knivil schrieb:

Es ist vielleicht nicht exakt, das was dort beschrieben ist: Drucke ich Enter, so ist mein Cursor ordentlich eingerueckt.

Ok, also eigentlich ganz was anderes... Kleines Beispiel zu den "Elastic Tabs":

int    a;
string b;
Foo    c;

Dieses Stückchen oben wird als Tabelle mit drei Zeilen und zwei Spalten aufgefasst. Setze ich den Cursor hinter "Foo" und erweitere es um "Whatever", rückt die komplette rechte Spalte automatisch weiter nach rechts:

int         a;
string      b;
FooWhatever c;

volkard

Badestrand schrieb:

Ok, also eigentlich ganz was anderes... Kleines Beispiel zu den "Elastic Tabs":

Er hat soch so viel Mühe gegeben, klarzustellen, daß es nicht elastic "Tabs" sind, und Du tritts ihn mit Füßen.

Tachyon

Badestrand schrieb:

...Da geht es um das Einrückungs-/Ausrichtungs-Handling im Editor, gespeichert wird mit Spaces.

Eben. Es geht aber um Tabs.

knivil

Also ich weiss nicht, ob es noch mehr Anwendungsbeispiele gibt, aber ... Variablen so auszurichten bzw. Kommentare dahinter sauber anzuordnen empfinde ich als Zeitverschwendung. Automatische Zeitverschwendung kann ich mir nicht leisten.

volkard

knivil schrieb:

Also ich weiss nicht, ob es noch mehr Anwendungsbeispiele gibt, aber ... Variablen so auszurichten bzw. Kommentare dahinter sauber anzuordnen empfinde ich als Zeitverschwendung. Automatische Zeitverschwendung kann ich mir nicht leisten.

Leisten könnte ich mir's. Aber die Zeitverschwendung ist sogar Codequalitätskontraproduktiv. Die natürliche Lese-Einheit ist die Zeile.

double                     SA = match->points*.5;

map<string,Site>::iterator i  = sites.begin();

// Helau!

Badestrand

knivil schrieb:

Also ich weiss nicht, ob es noch mehr Anwendungsbeispiele gibt, aber ... Variablen so auszurichten bzw. Kommentare dahinter sauber anzuordnen empfinde ich als Zeitverschwendung. Automatische Zeitverschwendung kann ich mir nicht leisten.

Als Anwendungsbeispiel würde mir noch einfallen:

int foo( const std::string& whatever,
         const std::string& foobar,
         const Whatever& yippie )
{}

Wenn man hier den Funktionsnamen verlängert, kommen die unteren Parameter mit nach rechts (oder nach links beim Verkürzen), finde ich voll praktisch. Aber allzu oft braucht man es wohl wirklich nicht. Was es aber m.M.n. nicht weniger cool macht, wenn der Editor das automatisch übernimmt (ist ja dann keine Zeitverschwendung mehr)

Badestrand

volkard schrieb:

Aber die Zeitverschwendung ist sogar Codequalitätskontraproduktiv. Die natürliche Lese-Einheit ist die Zeile.

Kann man sich sicherlich drüber streiten, aber ich finde

int         a;
string      b;
FooWhatever c;

übersichtlicher als

int a;
string b;
FooWhatever c;

, oder auch

... // blablabla
... // blablabla

besser als

........................ // blabalbla
.. // blablabla

. Wobei ich

double                     SA = match->points*.5;
map<string,Site>::iterator i  = sites.begin();

auch unleserlicher finde als

double SA = match->points*.5;
map<string,Site>::iterator i  = sites.begin();

. Ist wohl eine Sache des Maßes.

volkard

Badestrand schrieb:

Kann man sich sicherlich drüber streiten, aber ich finde
int         a;
string      b;
FooWhatever c;
übersichtlicher als
int a;
string b;
FooWhatever c;

Leeres Beispiel. Bei mir stehen nie lokale Variablen einfach roh da, ohne initialisiert zu werden. Und sie heißen auch nicht a b c, sondern haben keine senkrechte Struktur.

Badestrand schrieb:

... // blablabla
... // blablabla

besser als

........................ // blabalbla
.. // blablabla

Auch leeres Beispiel. Bei mehr Kommentaren der Art

i++;           //i wird um eins erhöht
cout<<i<<'\n'; //i wird ausgegeben

ist dieser Version hübsch. Aber Kommentare, die im Code was beschreiben, beschreiben den Zustand an der Codepoasition, wo der Kommentar steht, sollte also auch eingerückt sein.
Hier mal was uraltes

template<class C>
	void pop(const C &comparator)
	{
		assert(size>0);
		if(--size)
		{
			int p=1,c1,c2;
			data[0]=data[1];
			while(c1=p*2,c2=c1+1,c1<size)
			{
				//Wenn der Papa verschwindet, dann muß das kleinere 
				//Kind seinen Platz einnehmen, dessen kleineres 
				//Kind seinen, solange, bis jemand keine Kinder 
				//mehr hat
				if(comparator.lessThan(data[c2],data[c1]))
					c1=c2;
				data[p]=data[c1];
				p=c1;
			};
			//Und in die Lücke wird das letzte Element ganz 
			//normal eingefügt. 
			data[p]=data[size];
			while(comparator.lessThan(data[p],data[p/2]))
			{
				swap(data[p/2],data[p]);
				p/=2;
			};
		};
	};

genauso alt

void receiveARP(Packet &p)
	{
		//Arp timeout is a MUST but still not implemented!
		if(p[ARP_COMMAND]==ARP_COMMAND_REQUEST)
		{//Das war eine Anfrage
			if(p[ARP_TARGET_PROTOCOL_ADRESS]==ipAdresse)
			{//Sie war an mich, also antworte ich
				//Aber zuerst merke ich mir mal die Daten des Senders, denn
				//ich soll bestimmt demnächst auch was an ihn schicken.
				arpCache.add(p[ARP_SOURCE_PROTOCOL_ADRESS],p[ARP_SOURCE_HARDWARE_ADRESS]);
				//Und jetzt mache ich aus der Anfrage die Antwort
				p[ARP_TARGET_HARDWARE_ADRESS]=p[ARP_SOURCE_HARDWARE_ADRESS];
				p[ARP_TARGET_PROTOCOL_ADRESS]=p[ARP_SOURCE_PROTOCOL_ADRESS];
				p[ARP_SOURCE_HARDWARE_ADRESS]=macAdresse;
				p[ARP_SOURCE_PROTOCOL_ADRESS]=ipAdresse;
				p[ARP_COMMAND]=ARP_COMMAND_REPLY;
				linkLayer->send(p,p[ARP_TARGET_HARDWARE_ADRESS],ETHER_TYPE_ARP);
			}
			else
			{//Sie war nicht an mich, also werfe ich das Packet weg
				delete &p;
			};
		}
		else
		{//Das ist eine Antwort
			assert(p[ARP_COMMAND]==ARP_COMMAND_REPLY);
			arpCache.add(p[ARP_SOURCE_PROTOCOL_ADRESS],p[ARP_SOURCE_HARDWARE_ADRESS]);
			delete &p;
		};
	};

Ist wohl eine Sache des Maßes.

Klar. Für mich ist es vermutlich fast durchgehend störend. Andere werden es lieben.

Badestrand

volkard schrieb:

Leeres Beispiel. Bei mir stehen nie lokale Variablen einfach roh da, ohne initialisiert zu werden. Und sie heißen auch nicht a b c, sondern haben keine senkrechte Struktur.

Hat ja niemand gesagt, dass es lokale Variablen sind. Und bis der Compiler deiner Wahl das entsprechende 0x-Feature unterstützt, kannst du Klassen-/Struct-Variablen weiterhin nicht bei der Deklaration initialisieren.

@Hinter-Code-Kommentare: Mache ich selbst selten, sehe ich aber öfters mal in Code.

Oh, und du hast das Funktions-Paramter-Umbrechen noch nicht zerrissen, lass dir mal was einfallen.

volkard

Badestrand schrieb:

Oh, und du hast das Funktions-Paramter-Umbrechen noch nicht zerrissen, lass dir mal was einfallen.

Dieses Tuwort heißt "verreißen" und nicht "zerreißen". SCNR

Bei den Attributen tue ich's nicht, weil ich nicht nur desqwegen damit anfange. Funktions-Paramter-Umbrechen ist bei mir viel zu selten, um maßgeblich für irgendwas zu sein.

Badestrand

volkard schrieb:

Dieses Tuwort heißt "verreißen" und nicht "zerreißen". SCNR

Ok, sieht komisch aus, war aber im Sinne von "In der Luft zerreißen" gemeint

volkard

Badestrand schrieb:

volkard schrieb:

Dieses Tuwort heißt "verreißen" und nicht "zerreißen". SCNR

Ok, sieht komisch aus, war aber im Sinne von "In der Luft zerreißen" gemeint

Also doch verreißen.
http://www.redensarten-index.de/suche.php?suchbegriff=~~etwas verreissen %2F vernichtend kritisieren&bool=relevanz&suchspalte[]=erl_ou

Badestrand

volkard schrieb:

Also doch verreißen.

Von der Bedeutung her: Klar, ja. Der Begriff war aber richtig gewählt, du musst dir halt das "in der Luft" dazudenken. Ich musste mir ja auch orry ould ot esist dazudenken.

abc.w

Badestrand schrieb:

Kann man sich sicherlich drüber streiten, aber ich finde
int         a;
string      b;
FooWhatever c;
übersichtlicher als
int a;
string b;
FooWhatever c;
...

Lass mich raten, Informatik irgendwo im asiatischen Raum studiert?

ok, umfrage:

spaces : 1
tabs : 0

zum weiterführen der umfrage, bitte den block^^ kopieren, gwünschten wert um 1 hochzählen und hier posten.