[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [MISC] Programmering, kode-stil, indent, flere return



On Thu, 2006-02-23 at 07:04 +0000, Henrik Storner wrote:
> In <sslug@sslug> Hans Schou <sslug@sslug> writes:
> 
> >Må man have flere "return/exit" i en funktion? Må man udføre den sammme
> >operation to eller flere gange i samme funktion? Hvor mange indent må
> >der være i en funktion? Må en funktion være 2 skærmsider lang?
> 
> Det er vel i stort omfang et spørgsmål om at skrive kode, der er let
> at læse - og forstå.

Ja hvis programmet kører kun en lille smule langsommere, men det bliver
meget nemmere at læse/forstå, så hellere et læseligt program.

>  Specielt hvad indentering angår er der jo flere
> forskellige religioner - og derfor kan mange editorer jo også automatisk
> re-formattere kildekode til den indentering man nu kan lide.

Hvis man retter i eksisterende kode, så bliver man lissom nødt til at
gøre som de andre - uagtet at de har gjort det "forkert".

> Min erfaring er, at det især er i forbindelse med fejlhåndtering, at
> der bliver problemer. Det er jo også det, dit eksempel viser.

Nu er C jo ret nemt at lave logiske og runtime fejl i, så jeg mener at
man skal gøre så meget som muligt for at eliminere fejl.

> Ved sådan 
> noget fejl-håndtering kan selv den forkætrede "goto" jo være den pæneste 
> løsning. F.eks. kunne dit eksempel jo også være skrevet:
> 
> 	int ex3(void)

Tak tak, meget alternativt syntes jeg. Nu ved du ikke hvad min funktion
fill_with_data_1() helt præcist gør, så jeg har et andet eksempel med en
anden funktion hvor do_something_2() også påvirker noget ekstern I/O.

Jeg har også sat lidt kommentare ind, der hvor jeg plejer at sætte dem
ved lidt større blokke.

int ex4() {
	char * p1;
	char * p2;
	char * p3;
	int n = 0;
	if (!p1 = malloc(256)) {
		return -1;
	} /* if malloc p1 */
	do_something_1(p1);
	if (!p2 = malloc(256)) {
		free(p1);
		return -2;
	} /* if malloc p2 */
	do_something_2(p1,p2);
	if (!p3 = malloc(256)) {
		free(p2);
		free(p1);
		return -3;
	} /* if malloc p3 */
	n = do_something_3(p1,p2,p3);
	free(p3);
	free(p2);
	free(p1);
	return n;
}

Herunder har jeg valgt at negere så jeg får en lille blok lige efter
'if' og en stor blok efter 'else'. Jeg syntes det gør det nemmere at
læse.

int ex5() {
	char * p1;
	char * p2;
	char * p3;
	int n = 0;
	if (!p1 = malloc(256)) {
		n = -1;
	} else {
		do_something_1(p1);
		if (!p2 = malloc(256)) {
			n = -2;
		} else {
			do_something_2(p1,p2);
			if (!p3 = malloc(256)) {
				n = -3;
			} else {
				n = do_something_3(p1,p2,p3);
				free(p3);
			} /* if malloc p3 */
			free(p2);
		} /* if malloc p2 */
		free(p1);
	} /* if malloc p1 */
	return n;
}


> Det vigtige for mig er at det er let at se hvad denne funktion nu
> gør. Og i den forbindelse er fejl-håndterings kode "støj". Så
> kode i stil med dit eksempel 2 bliver meget let ulæseligt, hvis 
> funktionen begynder at brede sig over mere end een skærmside - 
> man mister simpelt hen overblikket over hvorfor man nu er indenteret
> ud i 8. niveau.

8x8 = 64 er lidt langt ude, enig.
  :se ts=4

> Flere "return's" i een funktion - det er noget man skal være
> forsigtig med, ligesom "goto" fordi det bryder det normale flow

Hvis det er en funktion der nærmest ikke laver andet end at checke for
fejl, og således checker for 32 fejl igennem et par skærmsider, så vil
jeg bruge denne if-return-if-return... struktur - eller måske ligefrem
goto hvis det ikke kunne være anderledes. CarstenS nævner noget der så
sådan ud, og hvis det var en masse fejlcheck, så syntes jeg det er i
orden.

Men ellers holder jeg mig til ex2(indent), da jeg syntes den er
"mere korrekt" - "stueren" om du vil.

> Ja, en funktion må godt fylde mere end en skærmside - det er en
> helt arbitrær grænse. Hvilken skærmopløsning, f.eks. ? Hvorfor

Ja køb en større skærm :-)

> F.eks. bruger
> jeg ofte tilstands-maskiner i mine funktioner, og det er sjældent
> et problem når blot hvert "case" element er til at overskue.

Klart. Kan noget puttes ind i noget der ligner arrays eller lister, så
er det nemt at rette/tilføje i listen, uden at røre ved den kode der
behandler listen og er gennemtestet.

/hans
-- 
Q: Hey, Johnny, What are you rebelling against?
A: What've you got?



 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2006-03-01, 02:04 CET [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *