4 ms·

That code is a bit too readable for that time period in games, hehe. See Doom: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/r_plane.c https:/

• freestyle24147 2y ago
  It's pretty easy to post a link to a codebase and say "this is unreadable". What do you find unreadable about it? What would you do differently now that there have been 30 years of software development between then and now?
  • caseyy 2y ago
    In the games industry, we generally try to write code that can be maintained by an average programmer. I would at least add more comments for context. Some teams have other ideas, like self-documenting paradigms with small functions and descriptive names. If a typical programmer doesn’t at a glance understand what each line of each function does on screen, what all the variables mean, what changing any line would do, what is the usual data flowing through the function, and what are the limitations of the function, then it either can’t be maintained quickly and cheaply, or maintaining it will introduce unforeseen bugs. But the key point is to not have a codebase that only a small core team can maintain. If you want to see examples of the difference between this and modern in C-like code, see Unreal Engine’s source code. It will generally, at least in areas of frequent change, be much easier to read. I would expect a mid-level programmer to understand 90% of UE’s functions in 10 seconds each. And more experienced programmers usually understand most functions they’ve not seen in UE in a couple of seconds. That’s not the case with Doom code. It took me up to 5 minutes to understand some of them. That means significantly worse readability. And I work in C++, C, C#, and other programming languages at a quite senior level in AAA games. So I don’t think this is a skill issue. It could be, of course.
• metadat 2y ago
  This source code looks perfectly legible to me. In fact, for C, it's the equivalent of T-Ball. Nicely and consistently formatted, relevant comments, sane structure, along with decent fn, and var names. What is your definition of "good, readable code?" P.s. I've emailed the mods, but a currently dead child comment from a new account states essentially the same thing (my vouch was insufficient to rez): https://news.ycombinator.com/item?id=40742493 https://news.ycombinator.com/item?id=40742493
  • LorenDB 2y ago
    Look at the R_MapPlane function. Indentation in if statements is non-existent.
    • metadat 2y ago
      What? What's a pretty severe nit pick. Especially for 30 year old C code. They didn't have no gofmt back then. We are spoiled today with the extreme consistency :) the skill of reading code includes reading even when it deviates from one's own preferred formatting (within reason, maliciously formatted code can be challenging, to say the least). I must respectfully disagree about this being an issue worthy of anyone's attention, especially yours and mine.
      • another2another 2y ago
        >They didn't have no gofmt back then. Didn't need gofmt as plenty of IDEs and editors had automatic indentation and syntax colouring already implemented. 1993 wasn't the dark ages you know.
    • stoltzmann 2y ago
      I honestly don't see anything wrong with how it's done, can you please clarify? This is pretty much exactly the formatting I used for C always.
      • caseyy 2y ago
        It could use more verbose variable names and comments to give the reader more context. So the bus factor is very low. If this programmer leaves the team and their large codebase like this is left behind, it will likely become a calcified legacy monolith of code that is expensive to maintain. Today, such code would not pass code review and possibly some automated pre-submit testing (Halstead’s metrics, Microsoft’s maintainability index, etc) in the AAA companies I worked for that cared about code maintainability. It’s not specifically about formatting or syntax. It’s more about whether a different programmer can look and understand exactly what it does, and what cases it handles, and which it doesn’t, at first glance. And the other programmer can’t be Carmack-experienced or grey beards — it has to be the usual mid-level dude. The code could even be written in a self-documenting code paradigm with parts extracted into small appropriately named functions. And it doesn’t need to be done to some perfectionist extreme, just a little bit more than what Carmack did. It just can’t be what we jokingly refer to in the industry as academic code — made for one author to understand and for every other reader to be impressed but not work with. 1993 was a different time, more code was academic, most of it was poorly documented. And there were good reasons not to have function call overheads. We even used to do loop unrolling because that saves a jump instruction and a few variable sets (you only increment the program counter as you go). So some of the reasons why this code is the way it is are good. But in readability, we have evolved a lot in the games industry. So much so that Doom’s code is pretty hard to read for most programmers. I asked around at work, in a large AAA company, and the consensus is that it’s archaic. But you know, it’s still good code, it did what it had to do, I’m not bashing it.
• LorenDB 2y ago
  Man, that could use a healthy dose of clang-format.
  • account42 2y ago
    How so? The formatting is quite consistent even if it is not the style you are used to.
• pjmlp 2y ago
  In that time period the game would have been written in Assembly, Doom was still years away.