# And what father is there among you, who,
# if his son asks for a slice of bread,
# will offer him a stone?
# or if he asks for a fish,
# will instead of a fish offer him a snake?
my $fish = 'one-fish two-fish red-fish blue-fish';
my $snake = 'oooh! a snake! ooh! snake! ooooooooo!";
(Unit test proceeds to insert both $snake and $fish into a cache object, does a little bit of extra manipulation to recreate the error condition, requests 'fish' back, and -- until the code was fixed -- got the contents of $snake instead.)
That's right. A successful combination of biblical allusion with Dr. Seuss and _Badger Badger Mushroom Mushroom_.
One of those reminded me of the following legend that gets passed around here at work.
A codebase had been maintained by a single person, who then left the company. When the other engineers took over responsibility for the project, they discovered, to their dismay, that it was almost entirely bereft of comments.
Amongst the tens of thousands of lines of code, they found only one comment, preceding an unintuitive bitmask operation:
/* gok */
Nobody could work out what on earth "gok" could mean, let alone why the previous engineer had chosen to leave that comment when they found no reason to comment any other part of the project.
Years later, somebody bumped into this chap at a conference and managed to ask him about the project and the significance of "gok."
"Oh, that's easy. It stands for 'god only knows.'".
Ad company I work for buys one of our traffic partners. I'm code reviewing their system to document it and find a comment describing how they defraud us.
Standard advertising fraud with faking traffic data. I handed it off to my manager who sent it to the CTO and from there it was dealt with at the executive level. Not sure all the details but I know the CEO of the other company went from picking furnishings for a new larger office to packing a box within a day or two and most of the rest of the acquired company was let go a short time later.
Netcat is full of great comments. Here's a good one:
/* I really want to strangle the twit who dreamed up all these sockaddr and
hostent abstractions, and then forced them all to be incompatible with
each other so you *HAVE* to do all this ridiculous casting back and forth.
If that wasn't bad enough, all the doc insists on referring to local ports
and addresses as "names", which makes NO sense down at the bare metal.
What an absolutely horrid paradigm, and to think of all the people who
have been wasting significant amounts of time fighting with this stupid
deliberate obfuscation over the last 10 years... then again, I like
languages wherein a pointer is a pointer, what you put there is your own
business, the compiler stays out of your face, and sheep are nervous.
Maybe that's why my C code reads like assembler half the time... */
netcat.c is by far one of the most entertaining code reads out there. Because of the unix networking / portability rants -- which are sometimes informative -- and also because the Hobbit was such a strange, scatalogical creature...
grep -in poop netcat.c
110:struct host_poop {
115:#define HINF struct host_poop
117:struct port_poop {
122:#define PINF struct port_poop
163:HINF ** gates = NULL; /* LSRR hop hostpoop */
169:PINF * portpoop = NULL; /* for getportpoop / getservby* */
336: cross-check the host_poop we have so far against new gethostby*() info,
340:int comparehosts (poop, hp)
341: HINF * poop;
349: if (strcmp (poop->name, hp->h_name) != 0) { /* case-sensitive */
351: if (strcasecmp (poop->name, hp->h_name) != 0) { /* normal */
353: holler ("DNS fwd/rev mismatch: %s != %s", poop->name, hp->h_name);
360:/* gethostpoop :
361: resolve a host 8 ways from sunday; return a new host_poop struct with its
365:HINF * gethostpoop (name, numeric)
371: register HINF * poop = NULL;
397: poop = (HINF *) Hmalloc (sizeof (HINF));
398: if (! poop)
399: bail ("gethostpoop fuxored");
400: strcpy (poop->name, unknown); /* preload it */
411: strncpy (poop->name, hostent->h_name, MAXHOSTNAMELEN - 2);
413: memcpy (&poop->iaddrs[x], hostent->h_addr_list[x], sizeof (IA));
414: strncpy (poop->addrs[x], inet_ntoa (poop->iaddrs[x]),
415: sizeof (poop->addrs[0]));
418: return (poop); /* inverse stuff, we're done. */
421: for (x = 0; poop->iaddrs[x].s_addr && (x < 8); x++) {
422: hostent = gethostbyaddr ((char *)&poop->iaddrs[x],
426: poop->addrs[x]);
428: (void) comparehosts (poop, hostent);
432: memcpy (poop->iaddrs, &iaddr, sizeof (IA));
433: strncpy (poop->addrs[0], inet_ntoa (iaddr), sizeof (poop->addrs));
435: return (poop);
437: return (poop); /* the full DNS hair */
443: strncpy (poop->name, hostent->h_name, MAXHOSTNAMELEN - 2);
444: hostent = gethostbyname (poop->name);
447: poop->name);
449: (void) comparehosts (poop, hostent);
453:/* whatever-all went down previously, we should now have a host_poop struct
456: return (poop);
457:} /* gethostpoop */
459:/* getportpoop :
460: Same general idea as gethostpoop -- look up a port in /etc/services, fill
461: in global port_poop, but return the actual port *number*. Pass ONE of:
466:USHORT getportpoop (pstring, pnum)
476: portpoop->name[0] = '?'; /* fast preload */
477: portpoop->name[1] = '\0';
495: strncpy (portpoop->name, servent->s_name, sizeof (portpoop->name));
509: return (getportpoop (NULL, x)); /* recurse for numeric-string-arg */
514: strncpy (portpoop->name, servent->s_name, sizeof (portpoop->name));
536: sprintf (portpoop->anum, "%d", x); /* always load any numeric specs! */
537: portpoop->num = (x & 0xffff); /* ushort, remember... */
538: return (portpoop->num);
539:} /* getportpoop */
994: gethostpoop wants a string and there's much gnarlier code out there already,
1002: whozis = gethostpoop (bigbuf_net, o_nflag);
1451: portpoop = (PINF *) Hmalloc (sizeof (PINF));
1545: gp = gethostpoop (optarg, o_nflag);
1572: o_lport = getportpoop (optarg, 0);
1584: wherefrom = gethostpoop (optarg, o_nflag);
1654: whereto = gethostpoop (argv[optind], o_nflag);
1669: curport = getportpoop (argv[optind], 0);
1713: hiport = getportpoop (cp, 0);
1719: loport = getportpoop (argv[optind], 0);
1740: curport = getportpoop (NULL, curport);
1749: whereto->name, whereto->addrs[0], curport, portpoop->name);
1768: whereto->name, whereto->addrs[0], curport, portpoop->name);
I've commented before that I feel that the PostgreSQL project is especially wonderful about code comments. According to the cloc tool, their C code has 700k lines of code and 221k lines of comments. That by itself isn't terribly impressive if you've seen a lot of the typical boilerplate comments a lot of IDEs place in code, but have a look at a sample of the actual comments : https://github.com/postgres/postgres/blob/master/src/backend...
Thoughtful, meaningful, and high-level. I aspire to this.
This is another one from the same project that I particularly liked:
/* So you want to know the relation between the hardware and the
software control constants. Well,
/---/\/\---||---\
| R2 C |
R1 | |\ |
e--/\/\----|-\___________|____v
2.5v-------|+/
|/
Kh = Ks/(2^ix) = R2/R1
Ih = Is/(2^ix)/dt = 1/R1/C
Capstan Drum
dt 1/1800 1/100
ix Cix Vix
*/
This tangentially reminds me of the fact that every time I'm writing a comment that's longer than 4 lines and explaining in detail why the thing following works as it does, then both the comment and the thing it was explaining won't survive the next hour.
When you need more than two lines to explain something, then something is wrong and you'd better fix it.
But maybe the act of writing the comment helps to free the brain to find a better solution.
This is absolutely not true. Perhaps you are not choosing the right time to sit down and comment. I'll usually put in quick comments as a module is under construction. Once it reaches stability (meaning, I am moving on to something else) the detailed comments go in.
Also, if we are talking about embedded there are a lot of comments that are invariant because they might explain details of the hardware interface this particular chunk-o-code might be dealing with. That hardware --external to the chip you are programming-- will not change unless a hardware revision is done, which is far less frequent than code iterations.
You can't see this from just looking at the code: there are four other systems that interact with the same database. I've managed to localise the problem by the timing of faults, it seems like Cassandra is erasing entries that aren't on its local list.
They won't let us change this because they're afraid of breaking the system.
If Alec's still in charge, you're effectively out of luck. If the boss has changed, try asking about changing it again.
Letting people ask these questions freely would destroy the community. They would grab all attention, and the focus would be on creating clever questions and answers, not providing good help for developers. Kinda how the biggest sub-reddits work; content that is easy to diggest grows quickly to the top.
> question is now closed, I think 528 "answers" is probably enough, no? :) – Jeff Atwood
It is annoying, though, how so many useful SO questions get closed for various reasons when they are just the question I want answered. Perhaps the real problem is Google giving a lot of weight to SO answers, even when they are closed?
It's the kind of thread that really has no home. Proggit would shoot it down for being frivolous, HN would probably do the same if it was a self-post.
I'm glad that StackOverflow leaves closed questions visible. A lot of the value I get from SO comes from opinion-y questions getting answered by experts.
I once posted a question citing reason I thought it was not duplicate even citing each of the few similar 'duplicate' questions I could find which did not answer my specific question.
Yes, and deservedly so. It's not a question with an answer, it's not even a poll. Other communities would close it as "Chatfilter" or "GTKY". What's interesting is that it was ever allowed on SO, and that it stood as acceptable for so long. And I wonder if the fact that there was a time in SO's lifecycle where it was accepted was important to the site's success. It's the sort of question that fosters community and good will in a way that "MVC 4 Validation using Data Annotations and Jquery" does not.
This is one of the things that really bugs me about a lot of open source and Github code: almost no comments.
It almost seems that there's a generation of programmers being taught that comments are a waste of time. I really don't know where this trend comes from. Lazy? I don't want to believe that.
For my purposes it is a huge negative mark if a programmer is not religious about commenting code. I will not hire someone like that. Why? Developing code is a huge financial investment, yes, but there are other metrics that are far more important than money. If you are doing something non-trivial it often requires a lot of thought, discussion, testing, experimentation, failures, iterations and decisions. Comments within code should be used to document some of this. Document intent, thinking, problem solving approach, corner cases, decisions, where/how it could be improved, performance notes, etc.
This and the code become incredibly valuable. It means that months or years later someone can go back into the code and truly understand what it does, why it does it that way, where it came from and, perhaps, how it could be improved. You don't need to engage in a research project in order to pick-up where the last programmers left of and continue moving forward. In addition to that I firmly believe a well-commented code-base is far more valuable during an acquisition than a thousand files of code with hardly a comment.
I can think of a number of Github projects I've come across with nearly zero comments. What you are looking at is dozens or hundreds of files vomited upon your hard drive that, yes, might perform a useful function at that point in time yet would be a nightmare to dive into to maintain them in any way. Before someone jumps down my throat: Just because something is FOSS it doesn't mean we should not critique such practices. If everyone took the time to thoughtfully document their code the FOSS ecosystem would probably evolve at a faster rate. Some of these packages are so dense they are virtually impenetrable without cubic hours of work deciphering the rats nest of files.
The counterargument is that code should be self-documenting. If code is complicated enough to need comments, refactor it. Behavior should be obvious from function and variable names. If you can't say what a method does in its name, it's too big. The best code transcends the need for comments.
What you describe about the development process, to write down the thinking and edge cases and decisions and such, is important but doesn't really belong in the source code. That stuff belongs in your issue tracker system or the commit messages. What other medium tries to embed a description of the creative process in the work itself? Da Vinci didn't write on the back side of the Mona Lisa the production process for his paints. Tolkien didn't explain how he created the Elvish language in the text of the novels. There's accompanying material for that.
But realistically for software, that accompanying material is not going to get read elsewhere, or survive long-term through migrations to different tools and hosts. So it ends up in the source as the only way to keep it with the code and visible ten years later. Commenting is a least-bad solution, not a good one.
And of course, policies for code commenting never work. You just get scintillating gems like "x+=5; //add 5 to x".
The idea that code be "self-documenting" is naive at best. Action does not necessarily infer intention, and without explanation can lead to assumption. To reach the code we end up committing a process of thought should have occurred by those who wrote it. For some things such as "boilerplate" code this may not be seen as significant. For others of increased complexity like explaining interactions between two pieces of logic, performing a complex set of logic or the expected usage of an externally provided interface comments are in my opinion essential.
In contrast to what you've said I completely disagree with the notion that the "best code transcends the need for comments". I'd argue the best type of code has the most effective comments in line with code to ensure the next person can gain with the least amount of effort clear understanding of both the rationale and of the functionality that lead to what they see before them.
> The counterargument is that code should be self-documenting. If code is complicated enough to need comments, refactor it. Behavior should be obvious from function and variable names. If you can't say what a method does in its name, it's too big. The best code transcends the need for comments.
I used to believe that too, but I now believe that that point-of-view only addresses the accidental complexities of reading code. Don't get me wrong, descriptive function and variable names are great and make understanding code much easier. But I think it misses the forest (program structure) for the trees (functions).
Where I get off that train is when trying to understand a program's structure. How do the modules decompose the problem being solved? Why was it designed a certain way? There's usually a combination of technical and domain knowledge that influenced the design. Sometimes, there's a philosophy that needs to be shared by the whole team to work effectively. I need to know all of that in order to effectively extend the program.
There are also times (though less common) that I believe comments are needed to understand even the most clearly-written functions. This is usually when one needs background knowledge to understand the function. For example, a mathematical derivation isn't obvious when you're staring at a line of trig functions. At the very least, code like that needs a reference to a Wikipedia article or a book.
> What you describe about the development process, ... , is important but doesn't really belong in the source code.
Except that in really big/successful projects, the proper places are outdated specs that end up buried in obscure unindexed archives. This can happen for a lot of reasons, technical debt, intellectual property acquisition, erosion of institutional knowledge due to personnel attrition, etc.
On the other hand, source code is forever. It is the thing that you cannot unknowingly get rid off without getting rid of (your ability to update) the product itself.
> Da Vinci didn't write on the back side of the Mona Lisa the production process for his paints.
If you were a curator of the Louvre Museum, your job would have been easier if he did.
Which is a myth. Try to come back to code five years and three languages later and see how self-documenting it is. It isn't.
I could maybe --possibly-- stretch disbelief and accept that if someone works with one language and one platform for a long time the code will be self documenting to that person or that team. This is not the case for multi-technology projects with generations of people touching the code base.
I'll give you a very concrete example. About fifteen years ago we spent three months authoring a tool in Visual Basic for Applications (VBA). This tool was used to automate certain aspects of the EDA (electronics design software) tool we were using at the time. The custom software was needed in order to vastly improve productivity with 1,000+ pin chips. The VBA tool effectively linked Excel with PCAD and reduced a twelve hour task to less than an hour.
Well, I have not touched VBA in probably fifteen years. The code is full of comments about the very things I described in my prior post: intent, design, thoughts, ideas, enhancements, problems, etc. After fifteen years of not touching the language or the application I can jump into that code base and be up and running within not much more than an hour.
It is hard to place a number on the value this adds to a project. It is nothing less than huge when it comes to supporting, maintaining, migrating and enhancing it.
> It almost seems that there's a generation of programmers being taught that comments are a waste of time.
That might be true. I had at least one professor who discouraged comments. He said, "I know how to read code." I can understand that in his particular case, he didn't need documentation for higher-level understanding. He taught us the algorithms and data structures being used and he gave us a boiler plate design that we had to conform to. All we had to do was fill in the function bodies and write a main() function.
Unfortunately, it's possible that some students might have adopted that as an overall attitude without recognizing that the context in which it was said invalidated the need for comments for any higher-level understanding. A lot of students looked up to this professor.
That's just a single example. I have no idea how common this is.
// Don't remove this comment, or the next line will break. WTF?!?
Turns out, we had mixed carriage returns and line feeds in our source. We had some UNIX coders, and some Windows coders. The Windows coders were in VS6 (ug), and the IDE showed the code perfectly. The compiler, on the other hand, was getting confused because one file had mixed CR/LF... So, essentially, it thought
// Comment
formatHardDrive = true;
It thought that pesky next line was still part of the comment. It wasn't literally formatting the hard drive... that was another bug we encountered, one time... oh, the places you'll go...
I think the best one that I didn't write was a long back-and-forth argument in a C header file where TRUE was defined as 0 and FALSE as non-zero. The original author of this product apparently had screaming fights about that being THE RIGHT WAY. Of course that surprised a lot of developers over the years and had been "fixed" several times only to be reverted back.
Pretty sad that all these examples are bad comments not good ones.
Here's a comment from some code that I posted to my blog. The idea was that this would explain in detail to someone reading the code what I was doing with the pieces of a wooden train set. This was critical to the operation of the program and I imagined that many of the readers of the code would need a careful explanation.
It turns out that I'd forgotten what this code does so the comment was helpful.
# The 15 possible pieces: a straight edge (which has $unit length) and
# is used as the measurement for everything else, a bridge (which is
# twice the length of the straight edge; it is actually supplied in
# two pieces but for the purposes of this program is considered to be
# a single piece) and a curve (using $radians_in_curve above the
# length of the straight line between the ends of the curve is
# calculated).
#
# Each entry consists of three parts:
#
# length: the length in a straight line between the ends of the piece
# at its centre.
#
# angle: the angle (in radians) between the straight line through the
# piece and a tangent to the curve at the piece's start. This only
# applies to curved pieces where the straight line is the line joining
# its two endpoints.
#
# count: how many of these pieces are supplied.
#
# Note that curves can be placed in either a clockwise or
# anticlockwise direction. The program detects this by looking at the
# angle. If it's non-zero then the piece has two orientations.
my %pieces = (
Bridge => { length => $unit * 2,
angle => 0,
count => 1 },
Straight => { length => $unit,
angle => 0,
count => 2 },
# Here's a curved piece, the angle a is $radians_in_curve, the
# length l of a side is $unit. So length is the distance between
# the points labelled s and f. Bisect the angle a you get a right
# angle triangle with hypotenuse of length $unit and angle at the
# vertex of $radians_in_curve/2. So the angle b is $PI/2 -
# $radians_in_curve/2. By simple trigonometry the length is twice
# $unit * cos($PI/2-$radians_in_curve/2).
#
# s
# C
# . . C
# . b C
# l . . C
# . C
# . . C
# . a C
# . . . . . . . C
# o f
#
# To calculate the angle to the tangent at point s (the angle c),
# note that the angle formed by os and the tangent is a right angle
# (since os comes from the centre of the circle). So b+c is $PI/2
# but b is $PI/2 - $radians_in_curve/2 and so c is
# $radians_in_curve/2
#
# s
# .
# . . .
# . b c .
# l . . .
# . .
# . . .
# . a .
# . . . . . . . . . . .
# o f
#
Curve => { length => 2 * $unit * cos($PI/2-$radians_in_curve/2),
angle => $radians_in_curve/2,
count => 16 }
);
That's beautiful! I have lately been encouraging all my team to take advantages of comments to document the high level business logic as it was at the time of development. It provides utility during code review and future dev, and it's a terrific CYA when debating with stakeholders about what they said they wanted then versus what they "remember" asking for.
That example is particularly verbose because I knew I'd forget it and it wasn't obvious what I was doing. A clear example of something shorter is:
// Briefly the algorithm goes like this:
//
// Slide a 16x16 block across the entire image from left hand corner
// to bottom right hand corner. For each 16x16 block perform a
// discrete cosine transform on it and then quantize the 16x16 block
// using an expanded version of the standard JPEG quantization matrix.
//
// Each quantized DCT transformed is stored in a matrix with one row
// per (x,y) position in the original image (the (x,y) being the upper
// left hand corner of the 16x16 block being examined.
//
// The resulting matrix is lexicographically sorted and then rows that
// match in the matrix are identified. For each pair of matching rows
// (x1,y1) and (x2,y2) the shift vector (x1-x2,y1-y2) (normalized by
// swapping if necessary so that the first value is +ve) is computed
// and for each shift vector a count is kept of the number of times it
// is seen.
//
// Finally the shift vectors with a count > some threshold are
// examined, the corresponding pair of positions in the image are
// found and the 16x16 blocks they represent are highlighted.
//
// Uses the FreeImage library (http://freeimage.sf.net/) to access
// image data
Also as it was interpreted at the time of development - the two should be the same of course but we don't live in a perfect world. If a comment explains exactly what the code is trying to do and why, and the "what" matches the code but doesn't match the client expectations then as well as fixing the code you know you might need to update documentation elsewhere too to make it cleare.
I really hate how heapq in python doesn't allow a comparator function. Stuffing tuples is the accepted solution, but it feels wrong and adds a bunch of unnecessary code when using heapq. Nice comment, but sub-par implementation.
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
Back around 2006 was an auto-generated file in Blender 3d's source code, if you edited it by hand and then ran one of the tools it would spit out a .h file with the contents:
.\" Take this out and a Unix Demon will dog your steps from now until
.\" the time_t's wrap around.
.sp
You can tune a file system, but you can't tune a fish.
Back in my heady startup days, I'd occasionally take my programmers to a local pub for afternoon chat and coding sessions. Code produced during these sessions often contained comments like:
/* First pint begins here */
/* Starting a second pint */
The idea being to keep track of code written during increasing states of inebriation. Interestingly, later analysis of that code showed no relationship between number of drinks and number of defects. (Of course none of us would ever get really smashed.)
# Circular references are a pain, yet so easy to avoid,
# however unpicking them at a later date can be hard
# and [python module name] especially so.
# Therefore I shall ignore this for now and use this poor quality
# botch to stop the code from breaking.
# I dream of a day in the future when I will be able to remove
# this crappy hack and the [project name] source code makes the world
# a better place.
# Until then I will cry myself to sleep each night.
There's a lot to be said about programmers, but in how many other professions do people actually feel like crying for not finding the best solution to a problem?
I used to work on simulations of industrial lifting cranes. Crane operators would use the simulator to plan a lift before going out into the field to execute it. This was 'round about 2008, when New York City had all of those cranes fall over in one year. Luckily, none of them were any of our customers, but every day was a new test of patience as we waited on the news to tell us what company was responsible so we could check out customer list.[1]
I'm now working on DOT road signing systems. The software I am writing will be used to figure out when and where to put up speed limit and warning signs.
What is really, super concerning is that, though I am capable of doing all of the math and physics that the job requires (and there is really no reason for you to believe me on that point, which makes the situation even worse), none of the other programmers I've ever worked with on these projects could.[2] The companies that hired me just got lucky that I typically go with the least-effort job application process and am too lazy to be constantly applying to jobs. There was no vetting process, it was just "take the cheapest guy we can get".
When people could die as a direct result of a programming error on your behalf, it tends to change your perspective on things.
[1] When the company ignored my analysis that certain parts of the data was logically inconsistent (this system used look-up tables to do everything, very little was actually simulated), I quit. As far as I was concerned, the fact that none of our own customers had been in the news was mere luck and I had no interest in being on watch with my hands tied behind my back when it finally did happen.
[2] The most recent fun defect I had to fix involved someone having added two angles together, one in degrees, the other in radians. That prompted this little thought-experiment in code: https://github.com/capnmidnight/UnitsOfMeasure/tree/master/U.... It works for some simple things and has an interesting side effect of helping document the code, which I realized when I failed to convert a particular poorly documented section of the code to this system.
You should. We don't certify programmers, so it's a very real risk.
On the other hand, I do not support the efforts of my state to attempt to license software engineers. As it's written, it really only seems like a protectionism racket to keep upstarts from competing with established firms. To whit: employees of S-corps are exempt. Way to miss the entire freaking point, Virginia.
At the top of the main loop of a heavily multi-threaded, iocp-based socket server written in K&R-style C. When I refactored it and ported to C++ I left the comment in.
Not exactly a comment, but I immediately thought of this:
"Whoa, that’s a full fog all the way. Double fog, oh my god. It’s a double fog, all the way. Whoa that’s so intense. Whoa man! Wow! Whoa! Whoa! Whoa ho ho oh my god! Oh my god! Oh my god! Woo! Oh wow! Woo! Yeah! Oh ho ho! Oh my god! Oh my god look at that! It’s starting even to look like a triple fog! Oh my god it’s full on! Double fog all the way across the sky! Oh my god. Oh my god. Oh god. What does this mean? Oh. Oh my god. Oh. Oh. God. It’s so bright, oh my god it’s so bright and vivid! Oh. Ah! Ah! It’s so beautiful! Oh my god. Oh my god. Oh my god! Oh my god, it’s a double complete fog! Oh right in my map. Oh my god. Oh my god, what does it mean? Tell me. Too much. I don’t know what it means. Oh my god it’s so intense. Oh. Oh. Oh my god." - Change 533404 by jim on 2010/07/19 18:07:00
Late one night in the early '80s I was bored and found myself paging through the code for WordStar (best I can remember) with 'ddt' on my Kaypro. Just page after page of Z80 disassembly and blocks of data… when suddenly I came across the words:
"Nosy, aren't you?"
In my sleep addled state that was one of the funniest things I'd ever seen.
Several of the answers revolve around dire warnings to not change or remove something even though no one may know why. They made me laugh and I've done similar, but I've also found that sometimes I stumble upon them again a couple years later and find I now have the skills to understand and optimize the code without breaking it.
This might be asking for trouble, but what are people's views on comments in normal cases? I once worked on a codebase where there were no comments, and people actively worked to remove them. It was a large Java Enterprise codebase and the idea was that anywhere I wanted to insert a comment, I should refactor and rename until the code explained itself.
At first this was horrifying, especially when I was thrown into this comment-free codebase with thousands of files. However it did make me write better code, knowing that I couldn't rely on comments to explain what I was doing. I wrote short functions that were easy to understand, and paid attention to all variable names. It definitely made me a better Java programmer, but outside of that project I still think comments have huge value. I comment my code a ton, and I think it makes it better. Anyone else ever worked in a no-comment zone?
I wouldn't call it a "no comment zone", far from it, but inline comments are nearly nonexistent where I work.
We write in the same way you did - short methods, lots of classes, descriptive (but not overly-so) variable names. The code should more or less document itself.
One place you will find comments are docblock style in projects providing an external API to allow us to generate the documentation from the code - it's the easiest way to ensure our docs are up to date.
The other is one or two word comments in the code, usually to avoid overly-verbose variable names. For instance, a variable named 'distance' might be immediately followed by 'in meters'.
As an added bonus, it helps make the code testable and improves (at least my) confidence in the results because complex logic is instead broken into lots of bits of simple logic which can more easily be thoroughly tested.
Knuth's "Art of Programming" series after 1985. He pretty much writes the documentation first, embeds the code in the documentation, uses compiler-preprocessors to extract, join and compile the code. He spent over a decade writing these tools himself since there wasnt really anything in existance to do that.
I used to read the nethack source code comments just for fun. Beyond jokes, lore, and the numerous not-implemented-yet features, it also included a small section regarding polymorph in fantasy games.
It asked: how should one handled multi-head/arms creatures? Do they get one amulet and one helmet per head? What constitute an arm? How many rings should a 4 armed creature be allowed to wear?
It nice when you see source code that is meant to be read as well as compiled.
Afaik the usual practice when you want to hammer to the type system in to the dirt is to reinterpret_cast a pointer to FROM to a pointer to TO, and then dereference it. Alternatively just do a memcpy()
Ahhh yes, I think this is in the Lion's commentary on UNIX source book. I remember our professor pointing out this comment and then telling us that we are indeed expected to understand it. The code that followed I believe implemented some behavior that made fork() work.
*If the system is so sick that we are unable
* to allocate a tiny chunk of memory, there
* is no much we can do here, kill this bitch
*/
exit(-1); //Seriously?
}
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
// PSD is not a good format. PSD is not even a bad format. Calling it such would be an
// insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
// worked on this code for several weeks now, my hate for PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.
// If there are two different ways of doing something, PSD will do both, in different
// places. It will then make up three more ways no sane human would think of, and do those
// too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
// that *these* particular chunks should be aligned to four bytes, and that this alignement
// should *not* be included in the size? Other chunks in other places are either unaligned,
// or aligned with the alignment included in the size. Here, though, it is not included.
// Either one of these three behaviours would be fine. A sane format would pick one. PSD,
// of course, uses all three, and more.
// Trying to get data out of a PSD file is like trying to find something in the attic of
// your eccentric old uncle who died in a freak freshwater shark attack on his 58th
// birthday. That last detail may not be important for the purposes of the simile, but
// at this point I am spending a lot of time imagining amusing fates for the people
// responsible for this Rube Goldberg of a file format.
// Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
// I had to apply to them for permission to apply to them to have them consider sending
// me this sacred tome. This would have involved faxing them a copy of some document or
// other, probably signed in blood. I can only imagine that they make this process so
// difficult because they are intensely ashamed of having created this abomination. I
// was naturally not gullible enough to go through with this procedure, but if I had done
// so, I would have printed out every single page of the spec, and set them all on fire.
// Were it within my power, I would gather every single copy of those specs, and launch
// them on a spaceship directly into the sun.
//
// PSD is not my favourite file format.
That's right. A successful combination of biblical allusion with Dr. Seuss and _Badger Badger Mushroom Mushroom_.