Hacker News Reader

Comment by colanderman | Hacker News Reader

Bad C code is bad C code. There's equally bad JavaScript, Ruby, and Python code too; none of those languages have particularly simple semantics.

Moreover, this particular example is due to compatibility issues across the multitude of platforms that Linux supports, necessitating support for versions of C older than any language you might like. Were Linux only ever to be compiled with a C11 compiler, this could be replaced with simply `static_assert(x)`.

And speaking as someone who's coded C for 16 years and makes a living doing so: it is rare that I write a macro; my Makefiles are about 5 lines long; I've never touched automake; and the only GCC flags I ever use (and use consistently) are `-std=gnu11 -Wall -Werror -O3`. Heck I wrote a cross-platform NES emulator last month following these rules.

There's a lot of bad C out there to find. Don't let that turn you off from writing good C.

View on HN

People often regard C code as inherently ugly because of nasty coding styles that were prevalent in the 80s and 90s – all local variables declared at the top of functions, lots of global variables, "space saving" indentation and often no whitespace between operators, bad separation of concerns. C can actually be a decent "high-level" language if you conform to a more modern style of programming. Codebases like Git and Nginx demonstrate that this is possible.

I generally agree with you, but C even at it's nicest is not "high level" except in the trivial sense of being having a recursive grammar (which assembly doesn't have).

The whole advantage of C is that it is a powerful, nice, and portable way to express roughly the same things you would otherwise express in assembly. Most of the really nasty undefined behaviour of modern compilers comes from forgetting this.

C is actually "high-level" in most aspects and we tend to forget that because of newer languages with lots of bells and whistles. C gives you a lot over assembly: functions with (mostly) no need to worry about calling conventions, automatic variables instead of dealing with registers and stack frame offsets, expression-oriented syntax that facilitates nesting of many operations within a single statement, structured programming support instead of scattered jumps and a rudimentary type system around values, pointers, arrays and structs.

Nothing fancy, but it means that the language can be compiled in a straightforward manner without any runtime support and a programmer can easily have a complete mental model of it.

Compared with languages like Ada, Modula-2, Turbo Pascal, Mesa/Cedar, Algol, PL/I, C is what we used to call a middle level language in those days.

And Algol, PL/I and their respective variants are around 10 years older than C.

Indeed. I don't want to give the impression that C is just assembly. It gives all the advantages you name, and they are very important.

But I still say that C is a way of talking about same things you want to talk about in assembly, albeit while automating some tedious but important things like register allocation. You are still commanding the computer at a low level: still telling it which byte to put on which IO port or memory location.

Of course you can build higher level abstractions on this -- but only to a point. C compilers go wrong when they imagine a C program lives in such a higher level of abstraction -- whereas the other languages thrive on defining such abstract machines.

But you can't actually directly address I/O ports in C, and directly addressing memory (via pointer arithmetic which oversteps the bounds of an object, or which puns the type of an object) invokes undefined behavior. Both those things depend on details of the underlying architecture, ABI, and operating system, and are abstracted away in C.

> People often regard C code as inherently ugly because of nasty coding styles that were prevalent in the 80s and 90s

Those code styles as still prevalent in 2016, speaking from the experience of occasionally having to look into how people write C code to integrate into Java, .NET, Python, Ruby at the enterprise level, which just stresses my point of view about the language.

Specially since outside HN bubble many don't even know what a static analyser or code review are all about.

Saw Hungarian notation used by two distinct developers in 2016. One of them freshly graduated and otherwise a halfway decent programmer. As far as I could tell both used it just as wrong as most developers did almost two decades ago. Bad styles find a way to live on.

What is wrong with declaring local variables at the top of functions ?

Because you generally want to put declarations close to their uses to minimize their scope? Reduce cognitive load and improve local reasoning?

But in general functions shouldn't really be all that long anyway (if they are, break 'em up!). I kinda like declaring my variables all at the top — I think it looks nice & clean.

Even in short functions, "declare it when it's needed" makes your program follow a data-flow style and enables you to use const more, since in many cases the initialization is the only assignment that you do to that variable.

While the parent technically said "at the start of functions", at least C89 (I don't remember about K&R) allowed declarations at the start of any block. This is not incompatible with minimizing scope - just introduce more blocks. And in fact, introducing a block to bound the scope of a variable allows a smaller scope than simply declaring it halfway through a function, as you can also end it early.

If you declare a variable as `const`, you have to initialize it during declaration. So you have to place the declaration exactly where the value expression becomes available.

Also, it acts as a declaration of intent and makes the data dependencies in a function more explicit.

If I declare a variable in the middle of a function, I am declaring intent that this variable shouldn't be used in the first half of the function – maybe the data it is supposed to hold cannot be available at that point.

Automake is nice if you know how to use it.

It provides a lot of things on top of a simple makefile...

You don't need it to write C, but everything that uses it is not "bad C code".

I wonder at what point even Linux will have to abandon the older dialects of C.

Why should it "have to"? (Honest question, I'm certainly not advocating keeping old styles for the heck of it.)

Old styes have a cost, and old compilers are not used very often.

At some point, even for a compatibility focused project like Linux, that cost must get too big for the benefit it provides.

>>Bad C code is bad C code. There's equally bad JavaScript, Ruby, and Python code too; none of those languages have particularly simple semantics.

The problem is that C is in everything. OK, not literally, but you know what I mean.

Bad JavaScript is easy to avoid. You just navigate to another website. Bad C though, not so much. Often times it's in the kernel or somewhere deep like that.

As a side effect of UNIX adoption in the industry.

Like it happened with the browser and JavaScript, C got adopted thanks to UNIX.

Before UNIX's adoption, many of us had a pleasant coding life using Turbo/Quick/Apple Pascal, Modula-2, Basic compilers.

No idea why you got so badly downvoted, your comment is pretty much spot on, bad C is hard to avoid.

I don't know either. It happens sometimes. I think it's just the bandwagon effect, and depends on the initial votes and their timing.

I think that is the case, people see a faded grey and just hit down.

Reply on news.ycombinator.com