Good code is like a love letter to the next developer who will maintain it

Post by AlotOfReading » Fri, Jul 21, 2023, 1:24 AM UTC

jiggawatts wrote: post #90

38 wrote: post #70

Earlier quoted context omitted.

> there is no such thing as good code definitely not true. this is good code: https://github.com/torvalds/linux/blob/master/fs/file.c this is good code: https://github.com/golang/go/blob/master/src/strconv/atoc.go its formatted, commented, direct. the fact that you struggle with writing time tested code does not mean that everyone does.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

    It’s written in an unsafe language.

    Double underscores everywhere, which are the bad alternative to namespaces seen in weak languages like C.

    Constants defined with lowercase and not actually marked as const.

    WTF does “BITBIT_NR(nr)” do!?

    Abbreviations everywhere: ofdr, nfdt, fds, fs, etc…

   Then there is a long-winded explanation of how they pack bits into an array of longs. Okay, why not make this a reusable module of code? Because C is a weak language, or because the Linux kernel is spaghetti with a dozen implementations of bit maps?

    Sorry… did I just see a data race just casually commented as “okay because it is faster if it’s horrifically unsafe?

Post by michaelsalim » Fri, Jul 21, 2023, 1:31 AM UTC

Alupis wrote: post #102

jiggawatts wrote: post #90

Earlier quoted context omitted.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

The issue so very many people fall into is assuming some foreign-looking codebase is awful. What people typically mean to say is something along the lines of "I haven't a clue what this does, haven't enough experience with the language to understand it, or how people use it". Go look at code written in "safe" languages like Rust and tell me you understand what it's doing any better than well written C code. You have…

Post by ww520 » Fri, Jul 21, 2023, 1:48 AM UTC

Post by WalterBright » Fri, Jul 21, 2023, 1:54 AM UTC

imoverclocked wrote: post #57

As someone who has gone back and read my old code as well as a lot of others old code, there is no such thing as good code. IMHO, the problem is one of cultural context which is often not shared between generations of coders. Languages and best practices can change so violently that best-practices one decade are often anti-patterns in the next. As a codebase outlives its best-practices, do you stick with them and ext…

Post by IggleSniggle » Fri, Jul 21, 2023, 2:15 AM UTC

lcnPylGDnU4H9OF wrote: post #118

buzer wrote: post #109

Earlier quoted context omitted.

Short names actually help with readability when they are commonly used. It's a lot quicker to go over the code when you don't need to read as much, similar to how one would write something like x+y=z in math instead of putting descriptive name for each variable in each step or using things "1€/kg" instead of "one euro per kilogram" (or let alone including kilogram's definition from SI standard).

Despite this, mathematical proofs still use a bunch of plain words to define things. In a programming context, if one has an “user” from the database, “user” is usually a better name than “u”.

    users.map(u => u.lastName)