|
It's been quite a few years since Code Complete was published. I really love the book, I keep it in the bathroom at the office and read a little out of it once or twice a day. But I don't think it's possible to call Code Complete, "Code Complete" when it doesn't have language features that even Delphi has, like anonymous methods and generics. What key sections are missing from this book, and what should be deprecated? |
|||||||||||||||||||||
|
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
The three problems in the 2nd chapter of 'Programming Pearls' and a thank-you note to Linus Torvalds. |
|||||||||
|
|
After having read both editions of Code Complete, and taken extensive notes (see a summary here), I'm not sure much should be added: methinks it's a book for advanced beginners and intermediate programmers (< 5 years in industry), for which it works very effectively in cultivating good habits, and a wider view of programming and software project management. Programmers who are moving beyond intermediate level (e.g. starting to learn multiple paradigms, including learning non-mainstream languages and multiple development processes) won't get as much out of it. But that's not the book's fault; it's not meant for them. If every working programmer just read Code Complete and nothing else, the average skill level in the industry would be raised 5x at least. In terms of things to be removed: words. Needless words, to be precise. The book is too long and the writing style can be tiresome. I also don't care for the Microsoft-centric approach (VB examples?!) and overly-mainstream perspective (e.g. caution/fear of recursion in Ch.17). Beyond Code Complete are books like The Pragmatic Programmer, which if applied, does take one into advanced levels of skill. Pragmatic Programmer assumes you're no longer doing silly things like using poor variable names or indenting/formatting inconsistently, thus freeing thinking for harder stuff. It's much shorter with more content per sentence too. But again, Code Complete has its place in boosting a naive, stumbling-but-curious programmer into a competent one. |
|||||||
|
|
How to determine the real problem you're solving, before assuming you know what it is. a/k/a avoiding the X/Y problem. How to ask questions effectively, online and in person. How to keep attacking a problem until you find the answer before giving up and asking someone for help. The flip-side: When to stop banging your head against the wall and ask someone for help. Clearly, I've been reading a lot of StackOverflow today. :-/ |
|||
|
|
|
Two sections that I would like to see would be writing secure code and somewhat in line with Andy Lester's suggestion of knowing what the problem is, or in other words, ensuring that you have the correct requirements. In regards to writing secure code, it's not that unusual these days to hear about various errors in code that lead to security issues and having the common problems summarized in Code Complete could go a long way towards helping developers avoid some of the problems. Likewise, now that we are starting to move in more of a web-centric environment, it might be appropriate to mention some of the common security issues around web development in such a section. Next, the issue of knowing that you are solving the correct problem and ensuring that you have the correct requirements. This is actually something that has popped up for me quite a bit in my own job and while others may help gather the requirements, it is still on the developer to implement those requirements and produce the final product that will be delivered. As such, having some information in Code Complete to demonstrate to the developer good requirements and also when you should take a pause to ensure that you are solving the right problem. As part of such a section it might also be a good idea to mention "non-programming solutions" as there are also situations where the program might be hiding a "process smell" that should be resolved outside of the program itself. This might be a little bit off topic for Code Complete though, but worth mentioning. All this said though, I do agree with the others in regards to making the book a bit less wordy. Likewise, over time I have found myself referring more to the project management and system design considerations as opposed to the source code discussions which leads me to agree with others that its a good book for junior to mid-level developers but over time it starts to offer less. Thus, it might just be a good idea to focus a bit more on what distinguishes a senior level developer for a junior and also add some additional information that would be of interest to a senior developer. |
|||||
|
|
For me, one of the great things about Code Complete was that it didn't just talk about writing code. The personality of a software engineer and the importance of understanding stakeholder needs is all in there. In my third edition, that would be expanded. Engaging with testers, customers or their proxies, support staff, other engineers etc is all critical to being a good engineer. So I'd have a chapter on requirements engineering, one on effort estimation, one on delegation, and probably some more. |
|||
|
|
|
Ebook/Kindle support! - I would love to own a copy on Kindle to replace my hard copy. As it's such a large book it's cumbersome to take around. We're programmers we should be leading the way in making our content available electronically! |
|||
|
|
