Please, stay on technical issues, avoid behavior, cultural, career or political issues.
-
7See this also stackoverflow.com/questions/132798/…– pramodc84Sep 9, 2010 at 14:14
-
This sort of question really annoys me. It can only spring from the mind of someone who sees the world in terms of black & white. Not every programmer has the same job and if it is the smallest common denominator that you are looking for, the answers below show that you just end up with a list of pet peeves.– Captain SensibleJun 24, 2011 at 18:22
Comments disabled on deleted / locked posts / reviews
|
90 Answers
The bug is in your code, not the compiler or the runtime libraries.
If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)
Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.
Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.
EDIT
Yes, my point #1 is overstated. Even the best engineered application platforms do have their share of bugs, and some of the less well engineered ones are rife with them. But even so, you should always suspect your code first, and only start blaming compiler / library bugs when you have clear evidence that your code is not at fault.
Back in the days when I did C / C++ development, I remember cases where supposed optimizer "bugs" turned out to be a due to me / some other programmer having done things that the language spec says have undefined results. This applies even for supposedly safe languages like Java; e.g. take a long hard look at the Java memory model (JLS chapter 17).
-
17I prefer to say "The bug is probably in your code", since I've come across bugs in runtime libraries a few times. I've yet to run into a compiler bug though. +1 anyway. Sep 9, 2010 at 16:24
-
29If you've never found a bona fide bug in the compiler, you're not nearly adventurous enough with your coding. ;) Sep 9, 2010 at 22:57
-
8@Chinmay, @spudd86, @Mason - yes ... and I've also found my share of compiler and library bugs in my 30+ years of programming. But in my experience, 99+% of bugs turn out to be (at least in part) the fault of my code. My answer deliberately overstates this to get across the point that you should always suspect your code first. Sep 9, 2010 at 23:06
-
5I don't get the irrational fear that people have with multi-threaded programming. I suspect the people who perpetuate this view, don't program much multi-threaded code. It's just not that hard. +1 for everything else though. Sep 13, 2010 at 17:19
-
4If you're working on the compiler, then the bug is probably in both your code and the compiler ;) Sep 16, 2010 at 12:19
- How to read other people's code.
- Code doesn't exist if it is not checked in Version Control System.
-
8+10000 if I could for the version control comment. History and change logging are absolutely indispensable and are the reason you should put everything in version control right from the start. Sep 16, 2010 at 12:20
-
2...and the repository has been synchronized to at least one other location. Important with DVCS, but also with centralized VCS.– Roger PateSep 27, 2010 at 11:37
-
For that matter, code doesn't exist unless a work item exists which authorizes the developer to write it. Dec 13, 2010 at 21:46
-
2I will plus one for learning how to read other people's code. It's more difficult that most of us realize, but an essential part of successful programming.– bogeyminDec 24, 2010 at 13:10
-
Floating point computations are not precise.
-
22
-
If anyone doesn't know what I'm talking about, read @Adam's link. It's an excellent summary of the pitfalls of floating point computation. Sep 9, 2010 at 16:53
-
1And if they don't know they can be amongst the set of people who ask on stackoverflow daily. Sep 9, 2010 at 23:20
-
1@Brian: So true. I wish there was a way to identify questions explained by floating point arithmetic. You could create a Stack App that displays a different floating point question every day! Sep 17, 2010 at 16:50
Don't stop learning.
-
1
-
3
-
7
-
1Related: Don't stop movin'! It's your life, keep on movin', get it right, you gotta get it right!– ocodoJan 16, 2011 at 3:19
That the #1 thing you can do to increase the quality and maintainability of your code is REDUCE DUPLICATION.
-
4
-
-
I would rather say: REDUCE CONDITIONALS. Each while/if/for is a potential bug.– zvrbaNov 20, 2010 at 7:35
-
1You know, the funny thing about DRY is that it's repeated everywhere. :) +1 Jan 16, 2011 at 9:11
Troubleshooting and Debugging Skills
They hardly spend any time on this topic in any of the programming courses I took, and in my experience it is one of the biggest determinants of how productive a programmer is. Like it or not, you spend a lot more time in the maintenance phase of your app than the new development phase.
I've worked with soooooo many programmers who debug by randomly changing things with no strategy for finding the problem whatsoever. I've had this conversation dozens of times.
Other Programmer: I think we should try to see if it fixes it.
Me: Okay, assuming that does fix it. What does that tell you about where the source of the problem is?
Other Programmer: I don't know, but we have to try something.
-
2I was about to post this. So much of a programmer's job is fixing bugs, and a lot of people tend to be incapable of doing so (especially in others' code).– DovSep 9, 2010 at 18:30
-
+1 I went from javascript/php to C# and fell in love with stepping through code. I wish that dynamically typed languages could do a much better job of this. Sep 15, 2010 at 11:54
-
Another weird behaviour is the programmer insisting that every part of his program is correct while the result if faulty. "-You don't need to print the array on the console to check if it's sorted because the line above is array.sort()." "-Well... you know, it's not working. There must be something wrong somewhere. You can't just defend your code at this point!"– gawiSep 27, 2010 at 18:59
-
2I think the point of debugging to validate your assumptions across your program. Sometimes, you need to go fishing for some clues. This has to be done systematically. It it perfectly valid to try something that might tell you something new. I do it often.– gawiSep 27, 2010 at 19:04
- Don't be clever; be clear.
- Use before reuse.
- Names matter.
- A function does 1 thing and does it well.
- Small is better than big.
-
2
The basics. Currently programmers learn technologies not concepts. It's wrong.
-
Yes and no. You sound like every prof I ever had in university... all of whom never made a lick of software in their entire life. Knowledge, without skills is useless in our profession. Sep 13, 2010 at 17:25
-
4+1, so true. Yes, this is something ivory tower types like to say, but it doesn't make it any less true for the rest of us in the trenches.– MAKSep 16, 2010 at 11:23
-
2
-
2No, basics like doesn't care about a typo but care about programming issues.– clrodSep 18, 2010 at 0:27
-
5It's easy to learn the steps to do something and often hard to find out when you should use it and more importantly when you could use it but shouldn't. Textbooks are particularly bad at showing the how but not the why (and why not).– HLGEMSep 24, 2010 at 18:35
Every programmer should know that he's putting assumptions in code all the time, e.g. "this number will be positive and finite", "this code will be able to connect to the server all the time within a blink of an eye".
And he should know that he should prepare for when those assumptions break.
-
6specifically state those with
assert()-- everywhere.assert()will help you document your assumptions and save you when you are wrong.– DustinSep 15, 2010 at 18:42 -
@Dustin +1 There's no way you can just remember all your assumptions - document them programmatically and you'll be told exactly when they turn out to be wrong assumptions. Sep 23, 2010 at 11:05
-
1...unless compiled with NDEBUG.– Roger PateSep 27, 2010 at 11:51
Every programmer should know about testing.
-
6
Learn concepts. You can Google the syntax.
-
Good in theory, except Google is terrible for finding specific syntax: Searching for terms like "object reference" or "this" given a gazillion results, and searching for idioms like "$?" give no results at all.– l0b0Jan 17, 2011 at 10:06
Unit Testing. This is a great way to codify your assumptions on how the code is to be used.
That's it's harder than you think.
While it's easy(ish) to put something together that works when used normally, coping with erroneous input, all the edge and corner cases, possible failure modes etc. is time consuming and will probably be the hardest part of the job.
Then you've got to make the application look good too.
-
3i think this is the source of the old saying '90% of the work takes 90% of the time. the last 10% takes the other 90% of the time'– GStoSep 9, 2010 at 14:41
-
I think a lot of people tend to consistently under-estimate the complexity. "How hard can X be?" - famous last words :/ Sep 21, 2010 at 23:20
-
Domain knowledge. The spec is never 100%; knowing the actual domain with which you are developing for will ALWAYS increase the quality of the product.
Big O notation and its implications.
Some useful references
-
I find Big O notation is one of the main things most computer scientists have a problem with (myself included)– RichardDec 13, 2010 at 19:42
Pointers, obviously. :)
-
3Pointers are only really necessary in a subset of languages for a small subset of tasks. For most tasks, you can (and should be able to) program as if the concept of a pointer didn't exist. Sep 9, 2010 at 16:29
-
14
-
5That really depends on what you mean by pointer. If you mean C-style pointers that you can manipulate (which is what I assumed), I would argue that a Java/C#/Python programmer doesn't need to know anything about them. If you mean pointer as in Java's "references", i.e., a pointer that can't be fiddled with, then yes, some knowledge of them is necessary, if only to prevent you from slipping up. Sep 9, 2010 at 23:25
-
@mathepic You'll be shaken to your very core if you were to learn how many CS students graduate each year that don't understand the first thing about pointers. If I hadn't gone out of my way to take placements each summer I wouldn't have even been taught about pointers in C or references in Java...– Mike BSep 13, 2010 at 14:54
-
5@Chinmay: A Python/Java/C# programmer that doesn't understand the concept of pointers is lost.
L = [[]] * 2; L[0].append(42)Different languages use different names, but indirection is essential everywhere.– Roger PateSep 27, 2010 at 11:55
Code Complete 2 - cover to cover
-
you really should know this before you accept money to program. If you find thing you did not know in it, consider either a career change or an intense period of self directed study to get you across it all. And then apologize to your co-workers. And it only covers the programming basics. Oct 7, 2010 at 0:58
Data is more important than code.
If your data is smart, the code can be dumb.
Dumb code is easy to understand. So is smart data.
Almost every algorithmic grief I've ever had has been due to data being in the wrong place or abused of its true meaning. If your data has meaning put that meaning into the type system.
-
2You had me all the way until you said "type system."– Roger PateSep 27, 2010 at 11:54
Which language and environment is most suitable for the job. And it's isn't always your favourite.
Divide and Conquer. It's usually the best way to solve any type of practical problem from scheduling to debugging.
True skill is reflected in the ability to execute a simple design well, not in the ability to make a complicated design work at all.
This skill comes from greater mastery of the fundamentals, not in mastery of the arcane. A high-caliber programmer isn't defined by their ability to code what others cannot (using higher level functions, advanced functional programming, what-have-you) but rather in their ability to refine perfectly mundane coding. Choosing the appropriate decomposition of functionality between classes; building in robustness; using defensive programming techniques; and using patterns and names that lead to greater self-documentation, these are the bread and butter of high-caliber programming.
Writing good code that you, or someone else, can come back to in a week a month or a year and understand how to use, modify, enhance, or extend that code is crucial. It saves you time and mental effort. It greases the wheels of productivity by removing roadblocks that you would have stumbled over before (perhaps interrupting your train of thought, or perhaps taking hours or days of effort away from other work, etc.) It makes it easier to concentrate on the hard problems, and sometimes it makes the hard problems go away.
In a word: elegance. Every class, every method, every condition, every block, every variable name: strive for elegance.
Never blame on the user what could be fixed with a cleaner user experience or better documentation. Often, programmers automatically assume the user is an idiot who can't do anything right, when the problem is a poor overall experience or lack of communication. Programs are meant to be used, and to treat the user with contempt is to miss the point of programming in the first place.
Every programmer should know how to use the debugger, and know how to use it well.
Short-circuit evaluation, althought it's one of the first thing they teach you about boolean operators.
How to accurately estimate how much time a feature is going to take to implement. More importantly, how to convey you're not bullshitting when you submit that estimate.
-
2or learn how to guestimate well and convey you're not guestimating... ;) Sep 16, 2010 at 6:27
Coding style matters:
- consistent indentation matters,
- consistent use of white space (e.g. around operators) matters,
- consistent placement of { } s matters,
- well chosen identifiers matter,
- etc.
... and good design matters.
Ideally, the programmer learns these things before (or during) his/her first code review. In the worst case, the programmer learns them when the boss tells him/her to make some non-trivial changes to some horrible code in a hurry.