Dårlig kode


Gå til bund
Gravatar

#1 arne_v 12. nov. 2019 16:18

Man skulle tro, at det var muligt at skrive hello world program korrekt.

Men se:

https://towardsdatascience.com/how-to-print-hello-...

Hvem kan finde flest tilfælde af dårlig stil i de eksempler?
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#2 Claus Jørgensen 13. nov. 2019 02:40

C: "#include<stdio.h>" burde være "#include <stdio.h>". main(void) kan skrives som main()

C++: "using namespace std" er ofte betragtet som dårlig stil. "return 0" er heller ikke nødvendigt.

(Og umiddelbart ville jeg argumentere for K&R stil for brackets i C og C++)

C#: Lowercase namespace er forkert.

... og så mangler der \n (newline) i halvdelen af eksemplerne
Gravatar

#3 Claus Jørgensen 13. nov. 2019 02:43

Men medium.com blogs er generelt skitskrammel. Så det undre mig ikke så meget.
Gravatar

#4 larsp 13. nov. 2019 07:15

#2 Nu vi snakker om stil går jeg stærkt ind for at bruge (void) ved funktioner uden inputs i C. Med () roder man sig ud i den gamle funktion syntaks og mulige overraskelser. Jeg har også set compilere brokke sig over ().

Jeg ville nok have skrevet den sædvanlige int main(int argc, char *argv[])
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#5 larsp 13. nov. 2019 07:19

Hvilket sprog er dette? .. den er nem :)

fn main() {
println!("Hello world");
}
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#6 arne_v 13. nov. 2019 16:27

#5

rust
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#7 arne_v 14. nov. 2019 02:06

C++ starter med et liniskeift.

C++ bruger både \n og endl.

VB.NET bruger ikke import.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#8 arne_v 14. nov. 2019 02:13

C standarden nævner kun:

int main(void)

og:

int main(int argc, char *argv[])

Men:

int main()

er ret brugt.

Der er meget gode grunde til at lave en funktions prototype med (void) fremfor (), da (void) betyder ingen argumenter mens () betyder vilkårligt antal argumenter (i C - ikke i C++).

Men der er nok ikke så vigtigt for main.

int main()
{
return 0;
}

void f()
{
main(1, 2, 3, 4, 5);
}

compiler men:

int main(void)
{
return 0;
}

void f()
{
main(1, 2, 3, 4, 5);
}

giver fejl - imidlertid er chance for at se den konstruktion i den virkelige verden nok meget lille.



The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#9 larsp 14. nov. 2019 08:39

#8 Ja, C er et pudsigt sprog. Man kan skrive 100% korrekte programmer der er de rene minefelter for den næste stakkels maintenance koder. Job security, I guess ;)

Men det er vel noget der plager de fleste sprog med lang historik og ønske om bagudkompatibilitet.
Stop using Google all the time: https://justsearchportal.com - Without distractions - Respecting privacy
Gravatar

#10 arne_v 15. nov. 2019 16:07

#9

C kode kan være svær at følge.

Jeg tror dog mere at det er sprogets natur end dets alder.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#11 arne_v 15. nov. 2019 16:09

#10

Jeg fandt et eksempel for at par år siden:


I notice that the result is wrong (two non-existing blank
lines).

It seems obvious that it must be due to handling of
CRLF.

But a quick look of the code showed that CRLF should
be treated like LF.

On the other hand the C code in question also
reminded my about how obscure C code can be.

static void unescape_url(char *url) {
register int x,y;

for(x=0,y=0;url[y];++x,++y) {
if((url[x] = url[y]) == '%') {
url[x] = x2c(&url[y+1]);
y+=2;
if(url[x] == '\r') {
if(url[y] == '%' && x2c(&url[y+1]) == '\n')
/* Ignore the CR in CRLFs */
x--;
else
/* Convert lone CR to LF */
url[x] = '\n';
}
}
}
url[x] = '\0';
}

And there is a bug.

if(url[y] == '%' && x2c(&url[y+1]) == '\n')

should be:

if(url[y+1] == '%' && x2c(&url[y+2]) == '\n')

[line 661 in SET_DCL_ENV.C for those that want to fix]

The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#12 arne_v 15. nov. 2019 16:25

#11

Fejlen har været der siden 1994-96.

Men ingen har testet eller lagt mærke til problemet som rammer CGI script slavet i DCL som processer TEXTAREA med flere linier.
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#13 Claus Jørgensen 15. nov. 2019 23:44

#11

Hvis koden ikke var saa obskurt skrevet saa ville det nok vaere nemmere at finde fejlen. F.eks. bedre variable navne...
Gravatar

#14 arne_v 16. nov. 2019 02:38

#13

Ja.

x -> writeIndex
y -> readIndex
x2c -> hexpair2char

ville hjælpe lidt.

Og hvis man så samtidigt undlod at genbruge buffer og i.s.f. havde separate input og output buffer ...
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gravatar

#15 arne_v 16. nov. 2019 03:02

#13

Det er iøvrigt ikke en uerfaren C programmør der står bag koden men en af de faste bidragsydere til libwww (1990'er WWW client lib).
The greater danger for most of us lies not in setting our aim too high and falling short; but in setting our aim too low, and achieving our mark.
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login