Slashdot Mirror
Lies Programmers Tell Themselves
itwbennett writes "Everybody lies to themselves now and again in both their personal lives ('my bathroom scale probably needs to be recalibrated') and professional lives ('this code doesn't need commenting'). ITworld has compiled some of the common lies programmers tell themselves. Here are a few examples: 'This bug won't take long to fix.' 'No one could possibly fail to understand my simple user interface.' 'Code is self documenting.' 'My homebrew framework will be nimble, lightweight, debugged, and easy to use.' 'I know this is dirty code, I will rewrite it later.' 'It's just one line... it won't break anything.' '"It works on my machine.' 'I don't need version control.' 'It's written in ____, so it'll be easy to ____.' What would you add to this list?"
"It always takes longer than you expect, even when you take into account Hofstadter's law."
"Sum Ergo Cogito"
Most of these are obvious and well understood.
Some (slightly less obvious) ones:
- Something must be wrong with this library (that is used successfully by everyone else)
- Theoretically two threads could try to change that variable at the same time, but it’ll never actually happen
- Just about anything starting with "no one will ever"
- Anyone who wants to use this class will look at the code / documentation and see that they can't actually use it in that (usually intuitive) manner.
Also can we please stop posting articles from itworld. They are all the same: tiny bits of content split over a ridiculous number of pages to maximize ad revenue.
Seriously, this is like 1990s levels of ad spamming. First you have the full window click through ad, then you have ads on every 10 word slide, a click through in the middle of the slides, and then just for good measure the last slide isn’t a content slide but yet another ad!
I feel like I need 10 levels of toolbars and bonzo-buddy running in the background to really appreciate the experience of this site.
My personal favorite! *sigh* Oh well.
"Quote me as saying I was mis-quoted." -Groucho Marx
"My facial hair makes me look interesting and makes up for my lack of social graces."
"I need to pick wacky, completely abstract name (that have nothing to do with function) for the new thing I made...that's a novel idea that will make it easy for people to remember!!"
ex: Yahoo, whatsapp, tumblr, Gentoo, etc etc
Thank you Dave Raggett
I'll document this code once I'm done.
n/a
Lie 10: itworld.com has interesting, informative, insightful, and meaningful content.
-73, de n1ywb
www.n1ywb.com
"Posting my article as a slideshow is a good idea"
We arn't beating a dead horse here. We are beating the pink stain on the floor where the horse used to be. While we are at it, lets talk about how shitty airline food is.
My contribution: this is just a prototype to show that this will work, the real version will be implemented properly.
with very few exceptions, any documentation that might come with code is completely
trivial and to the extent that it isn't, totally out of date
lets add annotations to the top of functions which merely repeat their signatures
and then run it through a formatter to rip out the bodies
then publish the context-less signatures as an html and pdf
and congratulate ourselves on having well documented code
oh uhh lies programmers tell themselves..
how about
this new website design is going to be great, our users will love it!
"I am a good programmer."
People prefer slideshows over simple lists.
c/p from the stupid slide show:
1. This code doesn’t need commenting
2. This shouldn’t take long
3. I can do it better myself
4. I’ll fix this later
5. It’s only a small change
6. It’s not a bug
7. I know what I’m doing
8. I can safely skip that test
9. I’m using so we’re good
My shit smells like Old Spice.
It's written in _______ so it'll be cross-platform.
"Well if you let the programmers run the show, things would be so much better."
Obliteracy: Words with explosions
http://deslide.clusterfake.net... OR http://desli.de/11IH for one ugly web page to read all at once! ;)
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Good code rarely needs commenting though. Too many comments are often an indicator of poorly organized code.
Dear person who thinks that "good code rarely needs commenting": the entire world wants to beat you senseless with a nine iron.
You're welcome.
"I am logging what is needed to trouble shoot a problem."
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
code is self documenting? lol, that is funny. the only code that is kinda easy for me to read is Visual Basic 6. even then, complex functions and API calls need documenting. forgot MSVC MFC gah... that code is complex. and don't get me starter with win 32 C.. even after reading Charles Petzold's books I'm still a bit confused as to how to write C programs from scratch. at least I have a book to read. i must be the only person not using Microsoft .Net or Java or some C++ GUI toolkit.
I would prefer to do with nine irons instead.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
1) People will enjoy this content more if it's in a slideshows.
2) It's OK if ad-blocking breaks my core javascript functionality.
3) Nobody is going to view this site in a modern browser.
#9 is why I write everything in C and Perl. I have zero delusions of the programming language saving me from myself.
Believing this while starting in a pale face with glassy eyes, and a small tear while explaining what I did today to my wife
* Changing X will have absolutely no effect on Y since I don't know any place where Y references X.
* I'll just take care of all the small bugs first before tackling this monster deliverable.
* Pulling this code out of the client and putting it into a store procedure won't break anything.
Occasionally living proof of the Ballmer peak.
I'm behind a firewall
will never crash under load.
Compiler warnings can just be ignored.
As soon as I've finished the main part, I will go back and deal with any sections I've flagged with # TODO
#DeleteChrome
"Screw comments! It was hard to write, it should be hard to read!"
I'll never need this code again so there's no need to document it.
... I will be a millionaire.
See also: this start-up is gonna rock! We'll all be zillionaires!
The lies listed in this article are all focused on doing unnecessary cleanup. Real life isn't full of down-time where we can polish everything perfectly. Anywhere you go where there are experienced programmers, you will see they avoid issues by not over-extending themselves. Don't tell yourself your code will be clean if you want it to be fast, or you want to develop it quickly. Don't tell yourself you'll fix it later if you honestly don't NEED to fix it later.
I get annoyed by programmers who get stuck in the weeds. Solve it, and move on.
About 80% of programmers I have met think this. It is used to justify pretty much everything else, including:
- "I can do this in in a couple of days. I'll forgo sleep." /could/ use it pretty much determines whether you're a good programmer or just a buzzword monkey.
- "If you don't understand what I am trying to do, you're just stupid."
- "I don't need much experience - I have Google and can learn quickly."
- "We need a programming language with lambda expressions!" - sorry, chump, if you can't write good code in Visual BASIC, I don't want to hire you. I'll never ask you to use Visual BASIC, of course, but whether you
.. just waiting for that cell to ring.
It should work in any browser.
"Our users will LOVE our new design. It's awesome!"
"Users love slide shows!"
I browse on +1 so AC's need not respond, I won't see it.
I have lots of time to get this code done.....I'll catch up on Slashdot's articles......
... and since I need to get the next release out in 10 minutes, I can safely put change X in the release build without testing.
that does not work _at_all_ if you have a halfway decent content- and tracking-blocker installed
What the ? I can't understand this code straight away without thinking about the problem or why they wrote it this way? It's shit!
Actually, a lot of problems are complex, and there isn't a single straightforward way to implement it. It could be that doing it the obvious way works - up to a certain point, and then the whole thing needs writing in a new totally non-obvious more complex way, in order to cope with x. (latency, bandwidth, text encoding, ACID compliance, European data protection law, occasonal data spikes which make the stack explode if you use a recursive function, certain servers only having python 2.6 on them still, etc. etc. etc.)
As theold adage says: "There's nothing more permanent that a temporary solution".
"I don't need to be knowledgeable in the operating system this will run on!" I'm always shocked about how little many developers, especially Windows developers, actually know about the OS they are writing software for.
I browse on +1 so AC's need not respond, I won't see it.
RTFM ... Everything is in the documentation....
Good code rarely needs commenting though.
This is actually true, but it's not interesting, because the #1 lie programmers tell themselves is "I am writing good code".
And really, it's always worth documenting corner cases, and everything non-trivial has corner cases. Even the somewhat trivial stuff like what a function does on bad input needs documenting, though I'd prefer unit tests to English for that stuff.
The purpose of the function, and the way the parameters are used, is often clear from the names, but the returned value doesn't have a name and is unclear more often than you'd think. But really, is the "remarks section" of the comments that is usually lacking. The summary and parameter documentation is often content-free, but comments about the return value, and especially any other detailed notes are quite valuable.
Socialism: a lie told by totalitarians and believed by fools.
We don't need to worry about locking or concurrency - It'll never need to be run on more than one thread/core at a time.
Of course it works. I wrote it!
Of course I looked at it, and judging by the misspellings, the person didn't even attempt to compile it.
I say this line often, and I'm usually right.
How is this a lie?
MABASPLOOM!
Simple code rarely needs commenting. If you have to write some convoluted or non-obvious stuff, then by all means, document. I'm just sick and tired of seeing 'comments' that are simply the paragraph name made into a comment, or state something that is obvious. In my experience, 95% of comments are either useless, or wrong, or both. Most of the time I ignore them.
As a tester my response usually was "I did it and if I can do it so will someone else".
it's still just as confusing & alienating
Look at Bluetooth's name origin...***technically*** you can see what they were thinking but that doesn't make it any less confusing:
via wiki
It's just too much...
I know that every "wacky abstract name" probably has **some** kind of funny quirky story...that doesn't make it a useful name
Thank you Dave Raggett
All these issues are irrelevant today, thanks to continuous deployment, Google buses, and node.js.
That my programming skills and what I am doing are the absolute most important part of this company and this business. Without me (us), this company would not run.
just to read 9 lines of text, here it is:
This code doesn't need commenting
This shouldn't take long
I can do it better myself
I'll fix this later
It's only a small change
It's not a bug
I know what I'm doing
I can safely skip that test
I'm using <NAME OF FAVORITE PROGRAMMING LANGUAGE HERE> so we're good
Women dig geeks now.
"There's no need to use <relevant thing I don't know>, we can throw something together in <irrelevant thing I happen to know>"
"We should use <thing nobody knows> because <it's trendy>"
Are you sure these are lies programmers tell themselves? Or lies they believe people wish to hear from them?
The classic.
... and don't soil the keyboard.
They will never realize that I have no idea what I'm doing!
Good code that rarely needs commented has very few lines. I don't care how good the code is when you get into a huge code base and there are no comments it's a pain.
Bluetooth is dead - Netcraft\\\\\\\
I've seen his tomb - he's buried in Roskilde Cathedral. It's about 30km west of Copenhagen, but you can get there with the Copenhagen city transit pass, and don't need to burn a trip on your railpass. Good museum of Viking ships there, which they'd found sunk in the harbor.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
And if it does, at least that's a good problem to have.
Dark Reflection
Anyone who knows Cobol/C++/Java/Perl can understand it perfectly.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Eh, I run a small business with four other developers (one partner, two employees). Before that, I wrote similar financial software for Familiar Evil Firm. Unless you have a proven track record in the field built on a good mathematical degree, this won't be the place for you. So, yeah, probably we would never end up working together.
I'm no genius, but I'm a highly methodical problem-solver, and over the last decade I've seen a torrent of would-be rock-stars. They lack any sort of theoretical depth, substituting familiarity with (what they've read on the Internet about) specific tools. Bunch of dullards. I want people who think carefully and imaginatively, not who have a good recollection of Functional Programming Languages 101.
Are you saying it doesn't work on my machine? How is that a lie?
Besides me and maybe one other guy I know, no one else can write good code. All others can't. Every project I've ever taken over were a complete mess and but none of my previous projects were ever a mess to someone who took them over. Projects that I have been involved on since the beginning get messed up because of the other guy, all of my stuff is correct.
Bottom line, every programmer believes that write good and have an ideal flow and that everyone else does not.
It's a boundary condition. It'll never happen in the real world.
I do not fail; I succeed at finding out what does not work.
"It works on my machine isn't a lie." it DOES work on my machine.
I see the point of 'My homebrew framework will be nimble, lightweight, debugged, and easy to use.' , however there are two other lies that partially counter-act it: "I'm sure that bug in the platform we're using will be fixed in a future release." and "Platform-provided APIs always save time and are more reliable than re-writing it yourself." The longer I've worked on my current platform -- now about six years -- the less I use its APIs and the more I use my own, because far and away the worst engineering mistakes I've made are getting sunk into the morass of trying to hack around the problems, bugs, or bad designs of platform-provided APIs.
I will never write another line of C++/Fortran/Perl/Prolog again in my life!
Well at least for Prolog that is true.
Just let us programmers handle the UI.
SJW's don't eliminate discrimination. They just expropriate it for themselves.
I read the GPs statement as "one of the lies I tend to tell myself"
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
These aren't lies. They are just mistakes.
People will read as many pages as I have entries in this list of x.
What? "good code rarely needs commenting" is absolutely true! The thing is, 80% of the code in big projects are arcane bugfixes and workaround limitations in APIs, this kind of code is almost impossible to be "good code".
"These specs are now exactly what the client wants, no need to think of eventualities"
"Nobody will ever need that feature"
"I don't need to comment that, it's obvious what it does"
"Once the prototype runs, it's going to be easy"
"I'll do it right, then I'll never ever have to touch it again"
"One last meeting to go to"
"There's no possible way this could become a security risk"
$change + "can't break anything"
"It COULD create a race condition in theory, but it can't happen in reality"
And finally, the ever popular
"I'll just slap something together now so we can ship it, I'll eventually get around to do it right"
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
http://xkcd.com/927/
Let us not forget that almost every framework you "should use" started out as a framework that "shouldn't be written." Only after enough people changed their mind, did the original author(s) become visionaries instead of "people who reinvented the wheel." I find that the tendency to "don't write that, it's already been written!" has been greatly blown out of proportion and people are allergic to actual software engineering. In other words, if they do more than extend / implement a predefined interface or glorified configuration on a single class instance... like heaven forbid they define an interface, base class, or object model with multiple things that derive it, then by god, they've gone too far! There is a time and place for frameworks, and realizing that the time and place isn't "every freak'n time" is just as important as not constantly reinventing the wheel.
"If I run into any problems on this huge project, I'll just post a question on Slashdot where everyone will respond with awesome, knowledgeable and intelligent recommendations."
"If we rewrite this from scratch, it'll be WAY better!"
Basically take a computer science degree and you'll hear all the lies in world in a short time. A truly good programmer doesn't give deadlines, doesn't make claims and doesn't brag without showing what he has done. Oh and it should be noted that 99.9% of all programmers have no F'ing clue how to write a useful or valid comment.
Here's a good one.
For those who seek perfection there can be no rest on this side of the grave.
How bad can adding just one little global variable be? I can be done before lunch!
I can easily manage a social life and programming.
This time it will work.
Though if we're talking outright, bare-faced lies I would suggest anytime someone tells you "two weeks" in response to a when or how long they *know* they are lying. 2 weeks is close enough to not cause panic, but far enough away to be forgotten or for more delays to "come up". If someone does tell you that, reckon on 3 months - minimum.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
* I need root access
* This brand new shiny framework/tool/whatever that does the exact same thing as seven other things we already used in previous projects is better than those others.
* I don't need to think about performance
* I can fully test all the use cases myself.
People that don't think that they need to fix compiler warnings produce programs that aren't always reliable.
And even if the code is free of warnings - there may still be a need to run 'lint', 'findbugs' or any similar tool that does a more thorough analysis of the code in order to detect problems that can grow over time.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Good code needs commenting, but "too many comments" also happens. It tends to be common when people think that comments should tell what the code does, instead of why the code does what it does. If you can't explain why you have a method/function in the comment for that item, there's a problem.
Not a sentence!
There is a time and a place for everything. The majority of the 'lies' in the OP will just make programmers even more insecure and they'll start over-documenting or implementing design patterns where they aren't needed. There are even times when it is right to write some dirty code. Don't be afraid to get dirty.
Oh, and I'm pretty sure that most frameworks start out as home brew. Innovation can be a good thing.
If I keep working these extra hours, the company will reward me with big raises and job security.
"I'll get back to work after reading the comments on this next /. article."
I think you have the wrong xkcd https://xkcd.com/974/ BTW, this one is on the door to my office.
--
.nosig
One of my first website coding projects was a simple survey. I modeled it after the numerous like/dislike surveys you see everywhere, both on the web and on paper. "Dislike" at one end, 5 radio buttons in the midde, and "Like" at the other end. Totally obvious how to use it, right?
About a third of the testers sent me email asking me what they were supposed to do.
Nietzsche said that a lie is something most often told to one's self, about one's self.
Competition Good, Monopoly Bad.
Our multiplayer servers can handle the load on release day
"Surfing Slashdot will help get me in the zone."
Everyone will use this new framework I wrote (even though it is a poor documented, non-intuitive replacement for the last framework I wrote that no one uses, both of which use a freely available, well understood, well documented API for all the heavy lifting which is what everyone IS using.)
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
I always like the rule that comments should explain why this code exists and is the way it is, and code should explain how it works.
One of my favorite comments: // initialize loopCnt to 2
int loopCnt = 2;
This could have been fixed as: // maximum retries
int loopCnt = 2;
Of course better would have been:
int retriesRemaining = 2;
I'll be paid fairly for the work I am doing....
It never happens...
Do not look at laser with remaining good eye.
Sure the code 'self documents' it is after all the final authority on what you want it to do.
However, I am tired put it in English please. I have just been dumped in the middle of your code what is the context *right here*. What assumptions are you making? What were you thinking at that time perhaps its not true or I am doing something wrong. Its been 3 years since I wrote this what was I doing here?
That is what comments are for, context.
"We can tune for performance after we're done implementing the required functionality."
A recursive sig
Can impart wisdom and truth
Call proc signature()
Expected state at start
Guaranteed state at finish
Gnarly hacks to keep an eye on
Keep the rest in your notebook and refactor the code until you don't need the notes anymore.
In an ideal world without clueless bosses, deadlines and working with less than perfect colleagues (ourselves included), sure.
I'll take a correct comment over no comment any day. Characters are free and much of the code I am forced to look at on a daily basis, was written by a monkey and comes in chunks of 1000+ lines of spaghetti. A comment, however trivial, that is also correct, is like a beautiful, naked and horny woman, with her heart set on fucking you senseless (or whatever passes for hot in guys these days, if that's your thing).
... whatever
Here's a short list of interface lies....
1) My error message is meaningful and helpful.
Sure. Like, "Can't find file" with no explicit reference ON THE DIALOG as to the the file name you typed in or the path it was supposed to be in, because God knows, we wouldn't want the user to be able to tell IN A SECOND where the problem was. No, let's make the user *dig* for it.
2) It's OK to shove warning and alert dialogs into people's faces.
After all, when we're at a restaruant, don't we *all* want the waiter to interrupt every few seconds with the night's special, warnings about peanuts, and the effect of alcohol on pregnant women. It's just as wonderful and helpful in software.
3) It's OK to make users wait.
Because users care *so much* about your little issues with processes or your inability to put things into separate threads while you keep the interface alive. I mean, when you're in a restaurant, don't you *love* it when the waiter ignores you because they've got something better to do?
4) It's best to steal input focus from the user.
After all, who knows where they'll type? And so what if they're already doing something else, what could be more important than MY little dialog? Modal dialog, of course, because they shouldn't do anything else until they pay attention to ME!
5) We'll help the user by refreshing his whole screen!
I mean, there's just nothing better than the waiter who rearranges everything on the table after you've started eating, just to make sure you have everything and the food is truly fresh! Of course, this couldn't be a bad habit of lazy, uncaring programmers who couldn't be bothered to get the screen or list right the first time before presentation. No. Certainly not.
Please do not read this sig. Thank you.
The BIGGEST lie that just about everybody in the country tells;
"I have read and agree with the End User License Agreement"
lol what a dumb list, with dumb implications
I know one language(probably PHP or VB.net) so that means that I am a programmer.
The corollary: I just read PHP for dummies, give me a $120,000 job now.
The only people who don't take GIMP seriously because of the name are people who spend large portions of their spare time dressed like the character from the movie.
Seriously, nobody else cares about your fetish - nobody. Get over yourself! The rest of us find you tedious.
This code is so simple it doesn't need any tests Always write tests -- yes, missing tests should be considered an important part of your technical debt.
Ian Ameline
This problem would somehow be solvable if I had root on this machine.
'Code is self documenting.' is not true.
'My code is self documenting' is true.
Are you complaining about software, or dining out?
Maybe you should just order pizza next time.
I was asked to teach a series of classes at my workplace on web design. When it came time to recommend an image editor, I ended up making the students use a commercial program. I would have much preferred to recommend GIMP, had it not been for the name. Not only does it call to mind a certain scene from a movie that many people are familiar with, but it's also a VERY offensive term for the handicapped. No way was I going to use it in a class environment.
True story. No kidding.
If you want to give your nightvision gear software the acronym "NIGGER," that's your right. But don't act surprised when people don't take it seriously or want to use it.
I gave up trying to look at the site after enabling a dozen sites and seeing even *more* in the Noscript list.
"Things we say when we're young and stupid"
I love the comments that are put in there as easter eggs, though. Deep within the original source of EQDKP was a comment above a bit of code that set the maximum year as 2010 for any entry. "Ambitious, aren't we?" it said, when it was written in 2000. Yeah, turns out that come 2010, people were still using modifications to the original and everyone had a conniption when their database broke on January 1, 2011.
Brief comments are good. Jokes are fine. Explanations of why you did it this way and not some other, obviously easier way are the best.
Occasionally living proof of the Ballmer peak.
Hold that thought for a second, my caddy is lagging behind.
Account -> Discussions -> Disable Sigs
How many times have you seen
// Increment the counter
// Keep track of how many filberts we have processed
// Finished another one
counter++;
rather than
counter++;
or, even better,
filbert_counter++;
The biggest lie developers tell themselves is, "why reinvent the wheel when we just save time by using some off-the-shelf framework"? I've never seen any time saved, in these circumstances. Everything works great until you inevitably encounter the one thing you can't do with it and you end up spending even more time adapting it, than you would have just writing your own framework in the first place.
And then there's the insanity that comes with trying to upgrade a mix of off-the-shelf frameworks at the same time. While I'm not a big fan of most developers' homebrew approaches, at least I'm not working with a black box, and I at least have the option of improving it over time.
"All ya gotta do is..."
what about my **other three examples**???
you know: Yahoo, whatsapp, and tumblr
you don't have any counterpoint to those abstract wacky names do you?
just accept it: nerds give the things they make really stupid, unuseful names
Thank you Dave Raggett
The sat part is, all of these ( referring to the comments ) are true, and we should / could improve.
this is just a prototype to show that this will work, the real version will be implemented poorly.
"Our users will happily beta-test this code, so there is no need to try it out in-house first"
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Biggest lie: I'm only reading slashdot because my code's still compiling.
"Almost anything a programmer says is probably a lie". Its true! I read it on /.
"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." — Tom Cargill, Bell Labs
Get free satoshi (Bitcoin) and Dogecoins
Exactly! Good code will have comments, in moderation, which tell you things you couldn't get simply by reading the code. Well-chosen names are part of those comments, however, and can be significantly more valuable when used appropriately.
Which would you rather read:
int x; // number of widgets // price of each widget (cents) // total price
// multiply x by y and store the result in z
int y;
int z;
z = x * y;
int numberOfWidgets;
int centsPerWidget;
int totalCents;
totalCents = numberOfWidgets * centsPerWidget;
Personally, I'd much rather have the latter version, despite the absence of formal comments. The descriptive names more than make up for the lack.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
"good code rarely needs commenting" is absolutely true
Not if the concept you're implementing is complex or, in hopefully rare cases, you need a clever solution. Look at the code snippet in this one and tell me you wouldn't like a few good comments:
http://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code
You were replying to a post about Gentoo Linux. So was I.
stop dodging + avoiding the facts...
I'm **the original commenter**...I made it...others replied, and I replied to them
I suggested "wacky abstract names" as another thing coders should avoid
you're pathetically trying to avoid confronting a truth that causes you cognitive dissonance....what I don't get is why? why is it hard to accept these names are dumb?
Thank you Dave Raggett
Just F5! http://programmingexcuses.com/
I'll take a correct comment over no comment any day.
While I mostly agree with you, it's worth considering that comments have a cost as well. Duplication of the same information between the code and the comments, in particular, increases the maintenance burden and makes it more likely that the code and comments will get out of synch in the future—and one incorrect, misleading comment can outweigh a thousand correct ones. For that reason, comments which fail to add any useful information should be pruned away no matter how accurate they may be.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Good code rarely needs commenting though. Too many comments are often an indicator of poorly organized code.
Dear person who thinks that "good code rarely needs commenting": the entire world wants to beat you senseless with a nine iron. You're welcome.
Please, can we print a hard copy of said code on a roll, wrap it around a bat (so it hurts "less"), and then beat him? My nine iron slices a bit these days. My third base pull is quite strong.
Works on my laptop.
When starting some project, and nobody else is working on it, you don't need version control. Yeah, yeah, personal process, blah, blah. I make backups after changes and I have almost never reverted.
That said, version control is vital if anybody else is going to look at your code. I used to resist it even in that case because I hated the idea that some server might come in and krunk my code. This was in the bad old days when CVS was dominant. I just didn't trust it. I'd create a ZIP file even more frequently if CVS was involved. Nowadays version control is very reliable.
To reiterate, when working alone there are times when it's just too much "look at me I'm running a company, here's my little briefcase", but when you get beyond yourself then yes, you need it.
I fully agree.
But something has gone horribly wrong in the world of managed code!
REM This is a comment in a toy language.
Docstrings considered harmful!
Socialism: a lie told by totalitarians and believed by fools.
So, you've not coded in Perl I take it?
Definition of anti-virus. Noun: A piece of malware sometimes purchased, designed to a) use up resources and slow down a machine, b)report activity to a central repository, and c) insure that it is the only malware on a given machine. Because of (c), it is one of the few pieces of malware that is REQUIRED to be installed in order to pass several security certifications. In a rare form of honesty, some anti-virus programs have correctly identified themselves as malware and disabled themselves. Others have identified essential Windows libraries as a virus and have managed to shut down the OS.
Great civilizations have lived and died on false theories. Don't mess up mine with a few facts.
I've never said "I could do it better myself" and it not been true. But then again, I usually have the sense to not rewrite working code if I can help it.
Also, I've found code can easily be self-documenting, though the quality of that self-documentation is dependent on the quality of the code itself and the programmer who wrote it. Usually the only time it is necessary to document code, it is not the code that needs explaining, but the reason for why the code must exist in the first place. This exemption void where prohibited by company policy, when documenting an API, or any code to be consumed by web developers.
Because users care *so much* about your little issues with processes or your inability to put things into separate threads while you keep the interface alive
This one is actually a tradeoff....would you rather have more responsiveness, or more bugs? Because as soon as you start adding threads, you'll add bugs.
"First they came for the slanderers and i said nothing."
GIMP is a questionable name...another commenter tells a story of people being reluctant to recommend it & it sounds plausible
what I found interesting is the **unbridled animosity** that questioning a beloved software's name...it really shows that there is something underneath the surface
I fsking love GIMP...use it all the time. I never have a problem recommending it b/c I just don't think that way. I didn't name it...it's weird sure but it's about the **usability of the software**
I *do* think the name GIMP & many others have caused **unecessary confusion** which absolutely does **hurt our industry**
when a tech consumer gets confused about their new product it causes a shockwave through the development process if that consumer confusion gets to Marketing...b/c then that just **compounds** the confusion...b/c we know what happens when Marketing tries to solve a tech problem!
Thank you Dave Raggett
Hazelnuts. They're called hazelnuts.
God damn Oregonians!
Chuuch. Preach. Tabernacle.
"I've been running it (on my programming workstation, with Admin rights) since 1987, and I've never had a problem with that module. You must have done something wrong on your (non-Admin) testing machine!"
Have gnu, will travel.
If your code is straightforward enough that it can be understood without commenting, then it's probably not very compact code, and has a lot of redundancies. So work on that.
Secondly, documentation isn't complete until the structure of the code is described. People who claim to have self documenting code rarely make the structure of their code clear. Maybe you do, if so then good job.
Thirdly, if I have to read your function to understand how it handles error conditions, it's not self-documenting.
"First they came for the slanderers and i said nothing."
All percentage bars are lies.
"I am a beautiful and unique snowflake because of the poetry of my code."
For your security, this post has been encrypted with ROT-13, twice.
"FizzBuzz is way too trivial to select programmers for basic competency."
Of course it does, sunshine.
"You're holding it wrong."
Ok. Technically, Jobs wasn't a programmer, and he almost certainly didn't sincerely believe that when he said it.
really?
your contention is that the coding mistakes in TFA are as well known as the reputation of airline food?
i question your entire thesis...we aren't beating a pink stain...
my evidence: most commercially available software
Thank you Dave Raggett
Can I help? //Sincerely, one more poor bastard who has to port legacy code.
...is probably "I'll only need to run this program once, so it's not worth putting much effort into".
Number two is probably "when I come back to work on this later, I'll remember what I was thinking".
The biggest lie here seems to be repackaging a list of very old, obvious, useless and overused ideas as "lies programmers tell themselves"
I am a respected employee and colleague, and by collaborating we will build
interesting products, to be proud of. By working hard and learning more, I
will be promoted and paid more. Ultimately, I will reach retirement age and
spend an enjoyable time with my family, in retirement, perhaps even as
a non-executive director, until I die, of old age, surrounded by my loving
family, in my own bed.
As. If.
Have fun with that ...
(R)ule in Hell or (S)erve in Heaven [R]?
Zirconia Starfighter, the developer of Synnefo LiveCD, used to say that compilation is rots crawling inside the PC...
Test: "Found a bug, we're just about ready to do a release"
Dev: "Here, give me a moment, hold my beer and watch this.. "
nuff siad
"I never comment my code. If it's hard to write, it should be hard to follow." ;-)
1) It's not a bug.
2) It's not MY bug.
3) Nobody will EVER do that.
4) There's nothing I can do about it.
I had this at work on Wednesday. I was capturing video for one of our shows, and it just stopped. It had done this to one of the others earlier, and she hadn't noticed (because she was busy in another room). Turned out the antivirus was popping up a model dialog box to let us know it couldn't update, which interrupted Premiere Pro and stopped the capture.
Delayed us by about 25 minutes.
Not exactly like this, but I was playing an old game (Star Trek: Birth of the Federation), and when you try to have it build an orbital mine it will rearrange the list so, should you double click to build to, you'll add a mine and then something else. Frustrating, endlessly frustrating.
(I hate this game, I don't know why I still play it. Cheating computer is cheating. Kill the human. That kind of shit.)
I'm a good programmer, and I have friends too.
There was an unknown error in the submission.
Yahoo - In pre-internet Australia the word "yahoo" was slang for a hyperactive idiot. The lead role in the movie Young Einstein was played by an Aussie comedy actor who stage name is "Yahoo Serious" (a contradiction in terms).
Whatsapp - is a play on "What's up?".
Tumblr - I will give you that one, it's missing an 'e'.
nerds give the things [snip] unuseful names - That's because many nerds understand a name doesn't tell you anything about the widget you're looking at.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
It's written in C++, so it'll be easy to fuck it up.
Feynman's story was about linguistics & form
Symbols are how humans communicate meaning.
If you think I'm wrong, hit 'cancel' when you post your reply & that will ***PROVE*** that a "name doesn't tell you anything about the widget you're looking at"
Thank you Dave Raggett
false dichotomy..."abstract/non-abstract"
how's this...**some** names are more abstract than others
names of things tell us their function **all the time**
if you want to prove me wrong, type out a long reply then hit "cancel" to post it
not the "preview" button...hit "cancel"
if names cannot denote function and are totally abstract then you will prove me right
Thank you Dave Raggett
I'll take a correct comment over no comment any day.
The comment I am reading is still valid and accurate.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Afterwards, there will be cake
Code without comments is not good code. Period.
An up pops a dialog box that says 'IE sucks balls'
But just like there is good code and bad, there are good comments and bad.
Mainly I just want functions to have comments telling me what to put in, what I get out, and any side-effects.
Yes indeed, the massive wall of empty XML tags approach to commenting. I've got an ample supply of those too, "I'll do it later I swear, I just did it to shut up the build agent!".
... whatever
The big reason this is proliferating even more with recent startups is that all the good domain names are taken, many by squatters who want tens or hundreds of thousands of dollars in exchange for the fact that they got there first. Can't pay them? You have to make up a name to get a domain for anything approaching a reasonable price.
No idea how to solve this problem, but it needs to go.
I delete more comments than I make. One place it's some guys initials and nothing else, another just has the word "bug" and a date, some are clearly wrong or outright betray a fundamental lack of understanding. Hence the qualification that the comment had to be correct. Incorrect comments are the bane of all existence, and in that context I would prefer no comment at all.
But working with this crap all day, and then coming across a comment that is both short, and accurate, even if it is blindingly obvious that Math.Round does in fact round numbers, is sweet relief.
... whatever
So, you've not coded in Perl I take it?
Perl is a disaster for many reasons. One of which it's TOO easy to write obfuscated code.
Another big reason is that it's great slogan, "There's more than one way to do it" is a big drawback too. That also leads to overly complex code.
Too quick.
Self commenting code is awesome. Quick and dirty gets the job done before a financial disaster happens. And basically all light nimble frameworks started out as a homebrew framework.
The list of lies that bozo says are sure signs of a bureaucrat not an actual developer. It has been my observation that when a programmer discovers they suck that they turn to trying to make up rules, then they look like an expert enforcing those rules but all they are in reality is a petty bully.
The problem is that the developer is often too clever for their own good. So while the code might be self documenting, there's no logical reason why something arcane is being done when something simpler does the same thing.
Take for example inline assembler, which is designed for a specific CPU type. So alone comes x86-64 and now NONE of that code compiles. So you have to either map it out to x86-assembler, and ... oh look the compiler itself doesn't support inline assembler for x86-64, or rewrite it in C and later figure out how to reassemble it.
Repeat for every CPU type. Rather instead of getting rid of the C function in the first place, stick a compiler directive in the code to switch to use the assembler code when compiling for that CPU, replacing the C function, and use the C function in environments without that cpu type. That is self-documenting.
I experienced the above in the Godot game engine. Their make system made a lot of naive assumptions about compiling on a C++11 compiler on a 32bit environment and it broke horribly if you compiled it for x86-64 on Windows with a compiler prior to Visual Studio 2013.
Likewise you find assumptions like this in libraries like zlib, libpng and freetype2, where minor changes made in the library aren't reflected in the documentation, so many projects that use these libraries are often using libraries with security bugs in them because they don't want to update the API used.
CS teaches neither coding nor theory.
Then It will work for this company.
It's just a one line change.
"The project will be better|cheaper|quicker|easier because we will|will not be going Agile|Waterfall|reading chicken entrails"
Followed at the end of the project with blaming the client for everything.
/* TODO */
"Emacs is better than vim!' ... now, if I could only find that asbestos suit
How many times have we witnessed this? We know how it goes down. That shitty application has two decades worth of bug fixes and business process embedded in it. Some of the business process might look like bugs or random side effects. An effort will be launched to rewrite it, and it will fail miserably, well over budget and several years late.
If the team is unfortunate enough to actually manage to create a working executable, they will find that it doesn't offer half the functionality of the old application and does not deliver the correct results half the time. So the team will start hurriedly patching code, accumulating rushed bug fix after bug fix until the entire thing is an unmaintainable quiltwork of patches and side effects. At which point the company will decide that the new application is awful and attempt to rewrite it. It's just the circle of life...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
we did not want to break a POS program, that the son of the BOSS wrote,
So we don't care how long the program takes,
It's not an uncommon belief. If the code is well factored, and has a good narrative, comments can actually be harmful. This is because comments have a very major problem: They can be updated, and are often updated, at a different time the code does. So it's not rare to find comments that are downright deceitful: They don't say what the code does: But what the code used to do, years ago, before the system worked. So making the code agree with the comments will break the app.
We have the same problem with most specifications: They are instantly out of date.
So what do we do? We want something that helps us explain what the code does, and yet cannot deceive us on whether it's true or not. We call those executable specifications and unit tests. If the tests don't pass, they don't reflect reality, and we have to figure out which one is right. If the Executable specs stopped running, then we know what broke them.
So I'd leave comments down to situations where I am stuck doing a level of language trickery that I do not expect my average reader to understand, but that I cannot actually avoid. So maybe a comment on a performance optimization, or on some crazy type conversion trickery in Scala. But every time I feel like commenting is necessary, I know my code is doing something I am not happy about.
I'll add color coding to lines joining devices to show if traffic is blocked, forwarded, or filtered today.
Having to work for a living is the root of all evil.
"I can write this in a slow, OO language using OPM (other people's modules) and it'll be quick to target, bug free, lightweight, and fast. Because, uh, faster hardware and, uh, derp" Also, "I don't need to learn C, I have (fill in the blank with the latest fad language that purports to save programmers from having to really learn to program)" and also "I can use the (fill in the blank with the latest agile / tricky / ultra-testable) technique to Make My Code Shine!"
Oh yeah, and this charmer: "I don't have to bugfix version-2 or older, it's perfectly reasonable to expect everyone to upgrade."
I've fallen off your lawn, and I can't get up.
you are inventing a distinction where none exists
common tactic when you are trolling
Thank you Dave Raggett
Here's a short list of interface lies....
1) My error message is meaningful and helpful. Sure. Like, "Can't find file" with no explicit reference ON THE DIALOG as to the the file name you typed in or the path it was supposed to be in, because God knows, we wouldn't want the user to be able to tell IN A SECOND where the problem was. No, let's make the user *dig* for it.
.NET's exception do this so much. Not helped by the fact that Visual Studio won't step into the standard library which would allow you to just get the filename or whatever from the debugger. Oh, yeah, and as a bonus it still does it when said filename (or whatever) is generated inside the standard library (e.g. when loading an assembly), so you have no way of knowing what it was trying to load.
yeah, What about them?
your comparison shows the scale of your concept of what happens in computing....in your mind, what happens in tech is equivalent to soda pop
you know what else doesn't make sense? why the candy Nerds are called 'Nerds'...or Mr. Goodbar (how can candy have a gender????)
you know why that point, and by logic your points, don't matter?
because we aren't talking about *candy and soda pop*
some of us do ***really critical*** work in tech & it is important for things to make sense in our interactions with ***non-techs***
Thank you Dave Raggett
You could rephrase the question as, would you rather have more features or more bugs? But rephrasing it like that would be implying that responsiveness is a feature, and that lack of responsiveness thus isn't a bug. More responsiveness can be achieved in different ways. Sometimes a separate UI thread is the best solution, in other situations a single threaded program with asynchronous operations is the best solution. But both are of course a bit tricky.
But if you decide that the UI is supposed to be responsive, then any nonresponsiveness would be a bug, which needs to be adressed, just like all the other bugs. It is entirely possible to make software, which over time becomes rock solid, if you focus on fixing bugs and not add any new features until you have taken care of the known bugs. Problem is that too often focus is on adding features rather than fixing bugs. And if you as a user want the bugfixes, you have to upgrade to the newest version, which also has all those new features with all the new bugs.
Might actually be a good idea, if you consider fixing of all the known bugs in both the old version and the new version to be release blockers, which must be addressed before releasing the new version.
Yes, and no. But don't make them modal, modal dialogs are never ok. It is ok to have modal dialogs to alert users about situations, that should never occur. But once they do occur, you then have to go fix the issue, which caused it in the first place. If you produce a modal dialog under normal operation of the program, you designed it wrong.
Then there are browser warnings, which is an entire chapter of its own. First of all, a browser should never display a modal dialog due to something a site is doing. But it is perfectly ok for the browser to display warnings. Unfortunately, we have lots of situations, where browsers have been too lax about something, and websites have started (ab)using that. Once browsers then start warning about things, that should not have been permitted in the first place, users will get too many warnings.
Unfortunately, this is not putting pressure on sites to fix those issues. Rather it is putting pressure on browsers not to warn users about sites doing things they shouldn't be doing. And it is teaching users to ignore warnings. And the worst part is, that this has moved on to tech support as well. If a user is in dialogue with tech support, and the user gets a warning, tech support will always ask the user to just click ok on every warning they get, and consider the problem to be fixed, if doing so makes the symptom go away. I have never once come across tech support, which would acknowledge that producing the warning in the first place, was an issue, that should be addressed.
Often legacy code without comments is better that code with. I find it the rule that commests are directly misleading, since code has evolved while comments has been static.
to take it on after I leave.
I completely redid some critical infrastructure just before leaving a company a few years ago. I moved 15 horribly configured, single-point-of-failure machines that needed serious downtime (so customers lost serious functionality) even for updates to an HA setup on 6 machines (and that was serious overkill but hey, it's critical). It went from basically no security to high security, completely transparent offline/online for each subsystem, everything scripted with auto-tested rollbacks (if desired, not required) and added a whole host of new features the product team was drooling over. I documented everything as completely as possible and did several days of training to make sure the ops team could take it on properly. I didn't use sexy new tech, just the absolute basics so there would be no excuses (you can do seriously cool stuff with BASH and subversion if you really want to...). The problem was that it just kept working... Zero problems, so none of the machines have even had a reboot since I left... And now no one (except me) has the faintest idea how it works...
Is Slashdot hoping to borrow some of the success of popular questions on Quora? Because there is little or no news value in it... See here http://www.quora.com/Computer-... for 203 answers and counting.
It's not a bug, it's an undocumented feature...
"my condescension, bullying, and persecution of others will go unnoticed if i call them social graces"
"the world will end if everyone does not look, dress, talk, and act exactly like me"
"i care about people and their lives, not how they dress"
"it is someone else's problem that I am so shallow I can't get over something as trivial as someone else's appearance"
"my lack of empathy towards others who aren't like me means I am strong and better than them and they are weak"
What is confusing about bluetooth? What is the better alternative?
Uniqueness can be a good thing; "irda" is worse IMO.
I am more freaked out bluetooth introduced Christianity, and thank you for alerting us that bluetooth cannot be trusted because all it wants is power and money under the guise of "uniting" (taking over, enslaving, terrorizing, destroying) anyone who dares to have their own opinion or think for themselves.
As soon as I've finished the TODO items, I can start the main part.
I can't use this code. (insert lie here) I must write my own.
Lie may be:
Not written in ______________, (i.e. ruby, java, perl...new fangled stuff...)
Nobody has thought of this yet,
I'm much smarter than they are,
Someone could probably put this to a song.
Always remember, untested code doesn't work. I see that over and over.
The useful comments are often not *what* the code is doing, but the other information about the code:
Why we're doing something this particular way. (Maybe the option that might seem obvious at first blush has issues that only show up in certain wierd circumstances.)
The overall goal of the function? Maybe it's doing some impenetrable higher math, in which case it can be useful to summarize the general intent.
Expected usage. Not all languages support design by contract, in which case it can be useful to have a comment giving expected ranges for inputs, valid bit flags, etc.
Basically anything that might be useful for the next person that looks at the code to help them get up to speed. You never know, that person could be you 10 years later. (It happened to me...I wrote some code, it got farmed out to outsourced labor to maintain, then a decade later I got called in to help debug some issues. Turned out to be flaws in the code that the subcontractors had added...but my earlier comments were useful in getting familiar with the code again.)
Yeah, I guess I'll take that promotion, I've always wanted to become a manager, I'll probably be good at it once I get the hang of it.
Star Trek transporters are just 3d printers.
As they say:
The novice programmer comments what he did.
The intermediate programmer comments why he did it.
The expert programmer comments why he did not do it the obvious way.
Star Trek transporters are just 3d printers.
How about "I'll reuse this component again later" and "this will be so fast I can just execute it in the main thread."
tomorrow.
CLI paste? paste.pr0.tips!
From my years in QA, I'd add: "It should work now. Try it again."
I worked for a Fortune 100 company that pressured its contracters to skip unit and system test and just put code in production without adequate testing.
The result was predictable. Programmers worked around the clock to fix their bugs in production. That was the corporate culture. Needless to say, the systems in question processed financial information, dollars and cents. They needed independent auditors to bring these practices to the attention of senior management.
Thank you. Those were all great examples. Grrrrr to the developers who told themselves those lies.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
- My code doesn't need testing, it's too simple.
- Testing is too time-consuming to warrant the effort.
- I've tested the code. [Most people don't appreciate what testing is.]
- [some technique/pattern] is always the best solution for this kind of problem. [It may be, but quite often patterns fit only somewhat.]
- [some language] is fast enough, here's an article with benchmarks. [Benchmarks can't measure your algorithms or software design.]
There's a ton. Most of them will be disputed :)
Only yesterday I heard this old chestnut again