Code Complete is an old book now. Is it still good advice?
In my new project I see a lot of code like below. I hate it but I'm not sure if I'm old fashioned or correct in thinking it should be 4 or five lines. Should I reject a code review for stuff like this?
return (HadoopSummary)ScopeCoordinator.getInstance().findObject(Scope.getFirst(), new Path<String>(SCOPE_PATH.split("\\.")));
I still hear recommendations for Code Complete so I assume it's still useful, but haven't read it myself. A somewhat old book I like is Working Effectively With Legacy Code, I think its main premise and prescriptions can help a lot of codebases out there even if not all of them, especially those in functional languages. (Namely, your codebase will be better the more you get it under test and the more you leverage OOP design principles.)
Your code snippet looks like normal Java code to me. :) Not great that it's so common but it's at least not unusual... Being one line or more lines for that piece of code doesn't really matter to me but I'd prefer the single line in this case: I'm viewing it in an IDE, I've got more than 80 columns, and the pieces of syntax are easy enough to spot I don't need vertical cues. (Unfortunately rainbow parens still seem to be a minority preference.)
My own quick context-free review of that: is it testable in junit? Can you substitute a mock (without using something like PowerMockito) for ScopeCoordinator.getInstance() and for Scope.getFirst()? May be better to make the instance a member variable that you can mock by just passing a different one in the constructor. Why is it Scope.getFirst(), unless this method is explicitly about finding the first of something so it's clear in context? For the 'new Path<String>(SCOPE_PATH.split("\\."))' part, that looks like it's going to be the same every time and not dependent on any runtime code so why not make it a static member? (Or an instance member you can mock, or maybe the enclosing method can take a Path as an optional param with the default being the static one.) Can the design be redone to avoid the type conversion or is it too late?
Not counting the fact that the book is old, i would generally not recommend it.
The contents and topics have not changed that much but the book is just rather horrible to read.
For whatever reason the author decided to ramble on for way to many pages instead of getting a point across in a concise manner. The whole thing should have been done in 300 pages instead of 900+. You will just start flipping pages without reading them and then put that gargantuan behemoth of endless words and sentences on the shelf (or return it to the library, delete the ebook or whatever).
That code does not look overly hideous (apart from the split magic string) just reformat it into a couple of lines.
> Code Complete is an old book now. Is it still good advice?
Software isn't a mature, rigorous field relentlessly marching forward into the future. Silicon engineering is, sure. But our field is constantly constantly rediscovering stuff from the 60's and 70's, and going through fashions and fads.
A software book being old really doesn't matter to me IMO. We still don't really know what we're doing yet.
In my new project I see a lot of code like below. I hate it but I'm not sure if I'm old fashioned or correct in thinking it should be 4 or five lines. Should I reject a code review for stuff like this?
return (HadoopSummary)ScopeCoordinator.getInstance().findObject(Scope.getFirst(), new Path<String>(SCOPE_PATH.split("\\.")));