Embracing The Cloud
public String CloudThoughts{ get; set;}
Sign In
Mike Leach
- Palo Alto, CA
I work at
Facebook
with a focus on IT and cloud architecture using the
Force.com
platform.
Disclaimer: The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary.
On this page....
Archives
Full Archives By Category
2010 Calendar View
October, 2011 (1)
August, 2011 (1)
May, 2011 (1)
March, 2011 (2)
February, 2011 (3)
January, 2011 (1)
December, 2010 (2)
November, 2010 (1)
October, 2010 (3)
July, 2010 (3)
June, 2010 (5)
May, 2010 (4)
April, 2010 (1)
March, 2010 (1)
February, 2010 (5)
January, 2010 (4)
December, 2009 (10)
November, 2009 (15)
Aggregate Me!
|
|
Categories
Amazon Web Services
Apex
Azure
Dialogue Script
Facebook
Google
Java Script
Jazz
JQuery
Salesforce
Visualforce
Personal Links
My Link
Blogroll - Fav Blogs
Monday, December 14, 2009
"IF" Happens
I've been using the phrase "IF happens" as a personal reminder to myself to be more vigilant in how code gets written. It refers to the use of "IF" statements in source code and is based on a similar
existential observation
.
It is more of a "style" than a "science". "IF happens" somewhere between functional and object oriented programming.
I could use big words like "
Cyclomatic Complexity
" to describe why IF statements are inherently bad, but I'm pursuing the less dogmatic and more pragmatic path.
When IF statements happen, they should ideally refer to a natural language function or property.
For example, this is pretty bad:
if(product.PurchaseDate < (TODAY - 30)){
//do something
}
This is better:
if(warrantyHasExpired(product)){
// do something
}
Nested IF statements are definitely bad. Please don't invite me to a pair programming session if the code even remotely resembles the following
:
if(something){
if(somethingElse || thatHappened){
//do this
}
else if(thisHappened){
if(thisEdgeCaseHappens){
//do this
if(ohYeahTheCustomerSaidThisMightHappen){
//do this
}
else if(thisVersion2FeatureStateExists && someVar != null){
//do this (if an exception hasn't already been thrown)
}
}
}
}
Yes, we've all written code like the example above and it's probably buried in the core of every project. After all, IF happens.
When IF happens, consider moving the code into a factory container class if the purpose is to construct other objects, use a switch/case block, and write an apology in the comments with a future dated reminder to come back and refactor.
A New Years resolution I had in 2009 was to fully embrace the functional programming aspects of Javascript. I mostly accomplished that goal through the use of
JQuery
and anonymous functions, but did not fully utilize a FP library like
underscore.js
.
On the server side, C# now has
Lambda expressions
and
LINQ
to promote more functional programming.
F#
was another language on my 2009 resolution list (and in fact was also on my
TODO list in 2008
) that I unfortunately made 0 progress on. I hope that changes in 2010.
"IF" can happen a lot in unit tests. Assert is really just an abstraction to using IF. The long term pursuit should be more towards Design-by-Contract using something like
Spec#
.
Oh well... "IF happens". But there's always room for improvement
Monday, December 14, 2009 12:32:16 PM (Pacific Standard Time, UTC-08:00)
Mike Leach
|
Disclaimer
|
Comments [0]
|
Comments are closed.