I wish the retard to who wrote these programs before me had the decency to write some documentation. Even a few lines of comments.

Been working through this refactoring project for about a month now. It physically hurts to keep going through this guy's old code.

Considering the code, are you sure you would like to see what they came up with without the restrictions of the language :P

@Voxera I'm not even sure if this guy would be able to communicate in a verbal language that I would be able to understand. We'd probably have to resort to rudimentary sign language, mostly involving rude gestures.

When I had the chance to ask the original developer about what lines 500-550 of one of his functions were for, I would often get a "oh you can delete that we don't use it anymore" response.

Fun fun times.

Code should be self documenting lol.

@byshiny Yeah. Though sometimes it doesn't hurt to know an intent behind something. Projects like suckless software are pretty self-explanatory without any comments since they're small and transparent in terms of intentions but I've worked with really shitty code bases a lot of times, and 9 times out of 10 the author didn't bother to explain himself, which turned the workflow into a whack-a-mole in mere minutes.

tl;dr, Self-documenting code is cool and all but it won't work out well when the author can neither write well nor plan ahead of time.

@byshiny This only works when the code is logical. If you have e.g. bit-twiddling hacks, you NEED to document next to them what they do, for example. Seeing magic constants being bitwise XORd all over the place will never self-document except for those already accustomed to such algorithms.

So no. You're only sometimes correct.

Further, just because code self-documents how it works does not explain WHY it was included at all. Sometimes, some seemingly superfluous code is actually necessary but you'd never know it at first glance. Adding a comment about why it's there can work wonders and is something the code simply cannot document on its own.

Please stop regurgitating old and aged dogmas without really considering their intent.

@junon What I'm trying to get at here is that the well written code proceeds well written comments. Ofc if you're going for something isoteric you should write some explanation. But most of the time structure, naming and reasonable abstraction helps a lot more than comments.