The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Im guessing mm isnt gong to be log here's abouts until sometime tomorrow arvo - but JIC - hope its been a blast. I just got back from the neighbour's 50th & I reckon yours would have been 2wice as good - and his wasnt at all bad;)
Passed out in a chair for an hour or two then got to bed about midnight. Got up at 10:00, head feels OK, but the lower back and legs are cramping up quite well.
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible." - Mr.Prakash One Fine Saturday. 24/04/2004
Our domain policy got updated yesterday. IE proxy setting locked down, set to a separate server for us poor outsourced labor. Google? Blocked. CP? Blocked. Internal web sites? Blocked. Every single one. How are we expected to work? I can't even log my work hours.
Luckily my VMs are outside the preventer's domain, so I could Google a workaround to restore it to the usual proxy.
Second attempt - all portable machines require dual security: fully encrypted hard disks and antivirus, both using the worst possible products. Including the computers that have a hard time running anything over MSDOS 6. He wins this one, nobody uses the damned things, so I suppose he's achived the highest level of security possible.
That was quick. He's already found my message. Oh well...
I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image.
What are the general thoughts and/or examples of 'working blue' in code comments? My thought is that, as the end user of our product never sees the comments, then it's whatever, but some do not agree (e.g. "not professional", etc., like devs tend to be "professional" anyway). For example, if I write a particularly kludgy piece of code (which is most of it ), then I'm fond of comparing it to horse excrement, etc. Not only does it alert me and anyone else as to what's up, it also highlights that I'm aware it sucks and that it's okay to have a bit of sense of humor about it, etc.
Comments are there to describe the code, not your your level of frustration with it. If you want to complain, use a blog.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
Comments are intended to clear up unclear code. Code should not be unclear because it is badly written, but because the problem it solves is difficult and requires some specific knowledge. That's where commenting should be used.
As such each line of comment should be treated like regular code that needs to be maintained. For example, if you change a bit of code that is commented you should check if the comment still matches the code. The less you need to maintain the better, so you best use comments only when they are really necessary (or rather, when you think they are necessary, it's a personal matter).
If you comment to much or to obvious comments are distracting and are a waste of digital ink and paperspace and only increase scrolling time.
I've written a little tip on writing good comments (or at least what I think are good comments). You might want to check it out: Write comments that matter[^]
Code should not be unclear. Not even for complicated problems. If it's unclear, it needs refactoring until it becomes clear.
There are extremely rare cases when a line or a small number of lines look awkward - most often workarounds for library bugs or the like. A comment in such case is OK, to explain the implementation awkwardness, but IMO that's about it.
There's another issue about commens. Some people try to add enough comments to make the design/architecture clear from comments. That's IMO a bad idea. Usually the architecture is an issue at a level higher than the compilation unit, having comments at that level won't help.
I agree with you completely.
Though sometimes time (or even personal programming skills) won't permit extensive refactoring and you'll have to make it as clear as possible within a given timeframe (and/or skillset). As clear as possible might still be unclear. When you've tried everything the least you can do is comment it. Show me one application that's slightly more difficult than Hello World with no unclear code and some faith in humanity will be restored
There's another issue about commens. Some people try to add enough comments to
make the design/architecture clear from comments. That's IMO a bad idea. Usually
the architecture is an issue at a level higher than the compilation unit, having
comments at that level won't help.
The architecture is at two levels higher. However the design is only one level higher and it specifically drives the implementation. So implementation decisions are driven directly from the design.
And attempting to leave such comments to the design isn't going to work if the written design didn't exist in the first place, or if it was incomplete or wasn't ketp up to date. So commants at that level then can be the only source of the actual design.
Additionally since architecture drives design which drives implementation an implementation decision might have originated from an architecture need. And because it is an implementation decision explaining why that decision was made, in the implementation, is entirely appropriate and correct.
Programmers don't all work the same way; even when dealing in static languages and using self-documenting naming conventions, people will take away different meanings at first glance.
How about when coming across a moderately sophisticated regex? Surely a one-line comment would explain its purpose quite effectively. It also helps in maintenance/debugging if you can read in plain terms what the developer had originally intended.
Sometimes a fist in the face says more than a thousand honeyed words.