Interesting read: Signs You're a Crappy Programmer (and don't know it)
-
-
I'm enjoying the Return points discussion in the comments.
Gives me some new info on the various situations.
People always say "always good!" or "never use this!" but it's never that black n white. There are always situations where one or the other is more applicable. The trick is to know such situations and recognize them when they cross your path.
-
IMO the "multiple return points" discussion is inherently connected with the "20 lines rule" discusssion.
If you allow longer methods, it's IMO senseless to insist on a single return point.
BTW, IMO the 20 lines rule is implicitely crap, since LOC is not a good measurement for anything at all.
-
My comments...
In general, multiple return points are discouraged, BUT in practice sometimes it does simplify things. If you have to write a lot of extra code just to enforce a single return point (for example, to prevent following actions from occurring if a previous step fails) your code is inherently more complex. Why not bail at the earliest opportunity? I don't think I've ever met a programmer who failed to grasp multiple returns, so the "maintenance" issue really isn't a starter.
I don't understand the author's problem with patterns. I don't really fixate on them, but at the same time I understand their purpose. Basically a pattern is a tried-and-true solution to a specific problem domain. Rather than redesign the wheel (probably badly), use a pattern.
-
@GalacticCowboy said:
I don't understand the author's problem with patterns. I don't really fixate on them, but at the same time I understand their purpose. Basically a pattern is a tried-and-true solution to a specific problem domain. Rather than redesign the wheel (probably badly), use a pattern.
I think his point was: It's crappy to explicitely go for patterns no matter if they are usefull for the actual application or not. For example, IMO the MVC pattern is relatively often used where it is rather useless, and in such cases it's often implemented incorrectly. (This automatically leads to the question if the pattern is applied at all, if the implementation is wrong...)
-
@ammoQ said:
@GalacticCowboy said:
I don't understand the author's problem with patterns. I don't really fixate on them, but at the same time I understand their purpose. Basically a pattern is a tried-and-true solution to a specific problem domain. Rather than redesign the wheel (probably badly), use a pattern.
I think his point was: It's crappy to explicitely go for patterns no matter if they are usefull for the actual application or not. For example, IMO the MVC pattern is relatively often used where it is rather useless, and in such cases it's often implemented incorrectly. (This automatically leads to the question if the pattern is applied at all, if the implementation is wrong...)That's how I saw it too: a warning against the "Pattern Craze" that takes too many people when they start learning about them, when they try to bolt them just about everywhere (especially where it's irrelevant and over-engineering), or try to include every single pattern of the GoF into every single project they take part in.
In short, I saw it as a warning against taking patterns as an end when they're nothing else than a mean.
