InfoQ Homepage Presentations Stop That! Questioning Dogmatic Programming
Stop That! Questioning Dogmatic Programming
52:51
Summary
Doug Hiebert questions conventional wisdom that is taken for granted when writing code, and presents alternatives by way of before-and-after examples.
Bio
Doug Hiebert is a software developer at Protegra, with over five years of software development experience. His passion for deeply learning technologies both new and old has often landed him in a mentorship role with those around him. His programming interests outside of his day job as a Java developer are playing around with Ruby and Scala frameworks and exploring aspects of functional programming
About the conference
SDEC is an annual conference hosted by Protegra where industry professionals share their own real-world experiences gained through delivering solutions.
Apr 26, 2014
-
Related Sponsored Content
-
Related Sponsor
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
Community comments
Disagree on Commenting
by Roger Fischer,
Re: Disagree on Commenting
by Frank Lloyd Teh,
Disagree on Commenting
by Roger Fischer,
Your message is awaiting moderation. Thank you for participating in the discussion.
Obvious comments are not useful. But there are many cases where the why is important and an abstraction of the how is helpful. Don't document the obvious, but help the future reader understand without having to read every line of code.
Also conditionals may be ugly, but they are easier to understand than polymorphism.
Roger
Re: Disagree on Commenting
by Frank Lloyd Teh,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree with you Roger.
When using third party libraries, I believe it is faster to browse through Java Doc than to read the code. So developers in Apache, Spring and other open source communities have my sincere thanks.
I like preventing NPEs by returning an empty Collection, if returning that does not have a logical difference with returning null. But seriously? polymorphism and Options over the simplicity of null checks? Didn't this speaker say we should prefer simplicity at the very beginning of this presentation?
If I have several layers of nested properties, each of which can be null and I'd just do one thing if any of those were null, I'll just wrap it in a try catch block.