Comment by kabdib | Hacker News Reader

Comment by kabdib | Hacker News Reader

For a while I had a gig writing HR software, and I read a bunch of books on conducting technical interviews. One particular gem of a book -- the title escapes me -- had example interview questions for some popular programming languages. I don't know about the COBOL, XML and SQL chapters, but the C and Java chapters were terrible:

Q: "How do you get the size of a file?"

A: "Call open, and then sizeof."

... is the only one I recall, but they all ranged from "awful" to "not even wrong".

Over my years of job hunting I'm slightly disappointed that I've never been given a question from it. :-)

This is all fun and games until you run into this kind of code in production. I once had to do an emergency rewrite of some firmware by someone who did not appreciate the benefit of functions. That one was so bad that I stopped looking at the original code for any reason because I was afraid I'd accidentally adopt one of the author's many, many misinterpretations of the hardware, or of base reality.

I've met programmers who didn't understand functions. Pretty well everything was one giant code block. He also didn't understand the need for compiler warnings and switched them all off.

Come to think of it, I refactored some code from a guy who didn't understand procs. He just cut & pasted code 'snippets' (a snippet being about a screenful) a couple of hundred times.

I find it difficult to understand such people.

During my first few years as a professional I worked on COBOL systems. COBOL doesn’t have functions, only procedures (no parameters, no return values, everything come from the global state). People were writing horrible programs made of one giant procedure that would go for thousands of lines and crazy level of indentation.

Everything was done through a small terminal emulator for AS400, 24x80 characters. Every programs were copy pasted from other places.

I eventually found a way to transfer the file out via FTP then upload it back that way I could at least use vim and see what I was writing but I was alone doing that.

I’ve been reprimanded after documenting my code via comments because I was using some vertical space that should have been instead reserved to code (when you only have 24 lines at a time, people become really petty about things).

That was around 2009 :p

I suspect some of these programming habits might have come from working on MATLAB. I think experience with MATLAB could be considered positively harmfull:- and it fosters a mentality of quickly thrashing out a piece of code with hardly any thought of structuring it into a systematic organized manner.

Hopefully adoption of python based tooling in many fields could help alleviate this in coming years..

In Matlab's defense, it has become a much better language over the years.

They even introduced first class functions more than a decade ago.

Was the book intended for people who didn't know how to program but were for some reason interviewing a programmer?

It’s not that unusual of a situation. You might have other technical teams but your lead developer(s) leave.

These days you can outsource technical tests to online businesses that specialise in that kind of stuff but that wasn’t always an option, particularly if you travel far back enough in time, and hiring contractors to support you during the recruitment process is often seen as too expensive for some businesses.

I once has to rewrite legacy firmware where the original author didn’t believe in .c files. You can still compile with only header files (but only if it’s all headers, no mixing what he did with normal structure), but I still wonder why he thought that was a good idea. He works for Facebook now.

That is a legitimate strategy for libraries so you don’t have to package everything. Not sure why why you’d do it for firmware though.

https://en.m.wikipedia.org/wiki/Header-only

Maybe the author was cargo-culting that?

Often having everything in one compilation unit results in a smaller and/or faster binary. I’ve seen this happen even when using LTO. It’s a common practice when developing firmware for small micros.

At work I do amalgamation builds where I `#include` 10s of files into 4 .cpp files so I can do `make -j 4` and end up with 4 compilation units.

It's stupid. It messes up `using`. It doesn't do incremental rebuilds. But it does clean builds fast for the release script, and it saves me from setting up cross-compilation on a faster computer.

It's not just stupid, it breaks the language. Things will be valid when compiled together that are invalid C++ when compiled separately. Your #includes will become more and more wrong over time, and if you ever change the grouping of files all kinds of random unrelated stuff will break.

It's also a really great idea, for the reasons you give. This is how the Firefox tree is built, and it gives massive compile and link time speedups. (We call it "unified builds".)

Some runtime speedups too. I guess that's from better cross-file inlining?

WebKit does it too, and there’s a certain style you need to write your code in for it to work. (Generally, namespace everything.)

I recall encountering compilers that required this - there was no linker essentially. Sometimes that was all you had available.

Most of the manufacturers eventually just wrote gcc backends for their architectures, but the era of crappy proprietary compilers went on far too long in many cases.

Microchip XC16, broken in a few places but functional and definitely allowed for .c files.

It wasn’t a small micro (16 bit dspic) and the code was far from fast. I think it was just cargo culting. He also removed all floats because “integer math is faster” but never tested it. Put floats back in and sped things up a couple orders of magnitude.

Another highlight, no main loop. Everything was in an interrupt. This allowed the code to run despite a very broken i2c driver because it was given a low enough priority that other tasks could preempt it while it was hanging indefinitely.

A lot of embedded compilers are bad or at least old. You frequently only get C and not C++, so you can use header files as a sort of template. Write all your real code to use a peripheral in the header, but wrap all the function names, global variable names, and peripheral register names in special macros. Then, in the .c file, you can include the header file multiple times as long as before each include you define a handful of macros that rename all the function, global variable, and register names in the header so they refer to the correct peripheral instance.

Reply on news.ycombinator.com