codezeilenlänge(konvention/empfehlung) und monospace schriftarten?

thordk

DrGreenthumb schrieb:

auf Deiner Kinoleinwand vielleicht... Ich finds immer sehr nervig wenn ich vor Fremdcode sitze und seitwärts scrollen muss.

kauf dir nen anständigen bildschirm die olle 80 zeichen pro zeile regel ist schlicht antiquarisch und hat keine daseinsberechtigung mehr.

otze

DrGreenthumb schrieb:

Wie kommt man überhaupt auf 120 Zeichen? Kann ich mir nur durch zu extreme Verschachtelung erklären.

(2 namespaceeinrückungen+1 klasseneinrückung+1 private/public einrückung+1 methodeneinrückung+1 If)*4er tab=24 Zeichen weg, bevor die zeile überhaupt beginnt. und mit den restlichen 56 Zeichen kommt kein Schwein aus.
Ohja, komplexe formatierte templates verschlingen auch noch den ein oder anderen tab...

Ich arbeite immer so, dass ich zwar seitwärts scrollen muss, um die ganzen tabs vor einer methode weg zu haben, aber ab dann muss sie problemlos auf den Bildschirm passen.

hustbaer schrieb:

Ich habe z.T. Bezeichner die alleine schon 40 oder 50 Zeichen lang sind

m_pCStrtCWhatASuperNameForMyClassButBlaBla??

LordJaxom

DrGreenthumb schrieb:

Wie kommt man überhaupt auf 120 Zeichen? Kann ich mir nur durch zu extreme Verschachtelung erklären.

boost::asio::ip::tcp::resolver::iterator it = resolver.resolve( boost::asio::ip::tcp::query( host, service ) );

Auf der zweiten Ebene (Namespace - Methode) sind das 111 Zeichen + zwei Tabs (x 8 Zeichen bei mir). Und innerhalb eines Headers kann man noch nichtmal usen oder aliasen, ohne das den Klienten zu vererben.

Artchi

Also 80 Zeichen finde ich heute auch nicht mehr zeitgemäß. Ich habe 100 Zeichen eingestellt, erreiche diese aber seltener.

Wenn ich Fremdcode anschaue, der breiter als mein Bildschirm ist, stell ich halt Zeilenumbruch ein. Wo ist das Problem?

Artchi

LordJaxmon! Yo, kann man aber auch schöner machen:

boost::asio::ip::tcp::resolver::iterator it = resolver.resolve( 
                                                       boost::asio::ip::tcp::query( host, service )
                                                       );

Oder auch so:

using namespace boost::asio::ip::tcp;
resolver::iterator it = resolver.resolve( query( host, service ) );

In einem Scope kein Problem und sauber.

LordJaxom

Ja, in diesem Fall ist das Importieren tatsächlich kein Problem. Aber bei einer einzeiligen Inline-Funktion schreibe ich dann doch lieber eine lange Zeile als zwei kurze, wobei die erstere nur einen Namen importiert.

Blödes Beispiel (analog zu oben, weil mir kein besseres einfällt)

// eher
return m_resolver.resolve( boost::asio::ip::tcp::query( host, service ) );

// als
using boost::asio::ip::tcp;
return m_resolver.resolve( tcp::query( host, service ) );

Da sträubt sich in mir irgendwas, das "tcp" gleich doppelt zu schreiben nur damit die Zeilenlänge schrumpft.

Ist wie gesagt ein blödes Beispiel, aber im Grunde sind wir uns ja auch fast einig, was die Zeilenlänge angeht. Zu schmal ist unzeitgemäß, zu breit (selbst wenn es auf einen Bildschirm passt) ist unleserlich.

hardy

können wir jetzt doch noch ein Cobolforum hier gründen ?

ich persönlich verwende 80 zeichen und Monospaceschriftarten, da ich viel auf dem Grossrechner zu tun habe und sonst vieles schlecht lesbar wird.
für c++ etc. verwende ich natürlich andere grenzen, da es einfach ein anderer einsatzzweck ist.

DrGreenthumb

otze schrieb:

(2 namespaceeinrückungen+1 klasseneinrückung+1 private/public einrückung+1 methodeneinrückung+1 If)

namespaces und private/public rücke ich gar nicht extra ein.

hustbaer schrieb:

Ich habe z.T. Bezeichner die alleine schon 40 oder 50 Zeichen lang sind

da würde mich ja mal ein Beispiel für so einen Bezeichner interessieren!

Gerade bei C++ gehts doch eigentlich recht kompakt, wie Artchi gerade an LordJaxoms Code gezeigt hat.

Eine 120-Zeichen-Zeile nimmt bei mir die ganze Breite des Monitors ein. Da würde nicht mal mehr eine Klassenansicht an den Rand passen. Ihr habt echt zu große Bildschirme.

Also ich muss auch zugeben, dass ich meine Zeilen eigentlich auch unter 80 Zeichen breite halte, aber es schon einmal 120 werden können, wenn ich mal etwas mehr verschaltle.

Nur mal als Beispiel:

VOID MainWindow::UpdateSearchView()
{
    LPWSTR lpWs = new WCHAR[pTb1->GetTextLength() + 1];
    pTb1->GetText(pTb1->GetTextLength() + 1, lpWs);

    if(wcslen(lpWs))
    {
        if(!SearchFiles.size())
			InitializeSearchView(pFolRoot);
		BOOL bAdded = FALSE;
		for each(File* pFil in SearchFiles)
		{
			WCHAR Path[MAX_PATH] = {0};
			if(wcsstr(pFil->Name, lpWs))
			{
				if(!pFil->FileItem->HasItem)
					AddSearchItem(pFil->FileItem), pFil->FileItem->HasItem = TRUE, bAdded = TRUE;
			}
			else if(pFil->ParentFolder->GetFullPath(Path), wcsstr(Path, lpWs))
			{
				if(!pFil->FileItem->HasItem)
					AddSearchItem(pFil->FileItem), pFil->FileItem->HasItem = TRUE, bAdded = TRUE;
                            // Hier sind es schon bei tab=4Z 
			}
			else
			{
				BOOL bAdd = FALSE;
				for each(LPWSTR lpWs2 in pFil->FileItem->Tags)
					if(wcsstr(lpWs2, lpWs))
					{
						if(!pFil->FileItem->HasItem)
							AddSearchItem(pFil->FileItem),
							pFil->FileItem->HasItem = TRUE, bAdd = TRUE, bAdded = TRUE;

						break;
					}
				if(!bAdd && pFil->FileItem->HasItem)
				{
					RemoveSearchItem(pFil->FileItem);
					pFil->FileItem->HasItem = FALSE;
				}
			}
		}
		if(bAdded)
		{
			ListView_SortItems(pLv1->GetHwnd(), SortItems, (LPARAM)this);
		}
	}
	else
		ClearSearchView();

	delete lpWs;
}

Also ich muss auch zugeben, dass ich meine Zeilen eigentlich auch unter 80 Zeichen breite halte, aber es schon einmal 120 werden können, wenn ich mal etwas mehr verschaltle.

Nur mal als Beispiel:

VOID MainWindow::UpdateSearchView()
{
    LPWSTR lpWs = new WCHAR[pTb1->GetTextLength() + 1];
    pTb1->GetText(pTb1->GetTextLength() + 1, lpWs);

    if(wcslen(lpWs))
    {
        if(!SearchFiles.size())
			InitializeSearchView(pFolRoot);
		BOOL bAdded = FALSE;
		for each(File* pFil in SearchFiles)
		{
			WCHAR Path[MAX_PATH] = {0};
			if(wcsstr(pFil->Name, lpWs))
			{
				if(!pFil->FileItem->HasItem)
					AddSearchItem(pFil->FileItem), pFil->FileItem->HasItem = TRUE, bAdded = TRUE;
			}
			else if(pFil->ParentFolder->GetFullPath(Path), wcsstr(Path, lpWs))
			{
				if(!pFil->FileItem->HasItem)
					AddSearchItem(pFil->FileItem), pFil->FileItem->HasItem = TRUE, bAdded = TRUE; 
			}
			else
			{
				BOOL bAdd = FALSE;
				for each(LPWSTR lpWs2 in pFil->FileItem->Tags)
					if(wcsstr(lpWs2, lpWs))
					{
						if(!pFil->FileItem->HasItem)
							AddSearchItem(pFil->FileItem),
							pFil->FileItem->HasItem = TRUE, bAdd = TRUE, bAdded = TRUE;
                            // Hier sind es schon bei tab=4Z 28 leerzeichen
						break;
					}
				if(!bAdd && pFil->FileItem->HasItem)
				{
					RemoveSearchItem(pFil->FileItem);
					pFil->FileItem->HasItem = FALSE;
				}
			}
		}
		if(bAdded)
		{
			ListView_SortItems(pLv1->GetHwnd(), SortItems, (LPARAM)this);
		}
	}
	else
		ClearSearchView();

	delete lpWs;
}

Ein doofer doppelpost(die lage von vorschau und absenden ist wirklich sehr unschön)
Als schriftart: Courier New, 10 mit clear-type

borg

hat das irgendeinen grund dass du den komma-operator so oft an stellen einsetzt wo es keinen sinn macht?

hustbaer

Dennis123, wenn das C++ sein soll, was für grässliche Macros braucht man dann damit das "for each(bla in blubb)" funktioniert???

Und das mit dem Komma Operator und mehreren Instructions pro Zeile, also wenn ich mit dem Code arbeiten müsste würde ich Anfälle bekommen. Viele lange sehr ungesunde Anfälle.

Shade Of Mine

hustbaer schrieb:

Dennis123, wenn das C++ sein soll, was für grässliche Macros braucht man dann damit das "for each(bla in blubb)" funktioniert???

Qt

Das oben ist aber mehr C code als C++.

man beachte zB das Single Entry - Single Exit

btw, es muss delete[] heissen...

EXDW

Ich packe immer alles auf eine zeile, und probleme beim lesen hatte ich bisher noch nicht.
ich finde es eher unleserlich wenn ein oder mehere brueche drinne sehen - das auge trennt das denn irgendwie, obwohl die funktion zusammen gehoert.

Ich hatte es aber bisher auch nur sehr selten das die zeichen ueber die breite hinaus ragen #gg
bei mir in der firma ist das so das alle grosse monitore haben, und bei jeden ~160 zeichen seitlich hin passen, und fuer debugger, output, doku und weiss der geier gibt es den zweit monitor - und zudem finde ich es persoenlich besser fenster nicht nebeneinander sondern uebereinander anzuordnen

Das mit dem starken drall in richtung C ist mir auch schon aufgefallen.
Das mit delete[] ist mir eigentlich schon klar, aber bei einem WCHAR kommt es ja nicht wirklich auf einen destructor an...(ist zwar immernoch nicht korrekt, aber die implementation ist ja ziemlich gleich)
Ohne den kommaoperator müsste ich halt einen Block anfangen und soetwas will ich eigentlich vermeiden(außer unten bei bAdded, ich weiß nicht warum).

Und das for each ist auch kein macro sondern ist bei VC8.0 standardmäßig dabei um über STL-container zu iterieren

CStoll

Dennis123 schrieb:

Das mit delete[] ist mir eigentlich schon klar, aber bei einem WCHAR kommt es ja nicht wirklich auf einen destructor an...(ist zwar immernoch nicht korrekt, aber die implementation ist ja ziemlich gleich)

Daß bei falscher Kombination von new[] und delete "nur" die Destruktor-Aufrufe unterschlagen werden, ist wohl ein weit verbreitetes Gerücht. Fakt ist: Was passiert, wenn du new[] und delete mischst, gehört in den Bereich undefined behaviour - und das kann auf deinem nächsten Rechner auch einen Totalabsturz bedeuten.

Also mein hauptproblem mit dem new ist eigentlich, dass ich es als malloc ersatz missbrauche, obwohl ich noch nie in C programmiert habe.