View Single Post
Old 05-13-2010, 10:56 PM   #7
Capt Jack
check your head
 
Capt Jack's Avatar
 
Join Date: Oct 2005
Posts: 4,174
Capt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of coolCapt Jack is the epitome of cool
Ive been doing the code toad bit for something close to 30 years.
so, some "old skool" thinking:

robust vs flexible vs quick vs (wtf ever). there quite often arent really any hard and fast rules for getting from A to B. in some shops, they do enforce coding standards and can be quite nazi-esque about it at times....others, not so much. seems any one thing can be done 1000 different ways, and everyone you meet in the industry seems to have a different take on it.

the shops Ive worked in allow quite a bit of flexibility and "personality" to be included in code. many times because they will be coming to YOU when something isnt right. robustness, longevity and durability can be built in from the start and often should be designed in before you ever code line 1. do it once, do it right.

thats all fine and good...right up to the point they (the user) change their minds. that can and does muck everything really fast and can flush your complex logical flow right down the drain.

code backwards. start at what you (or they) want and design a path backwards to your starting point. oft times that starting point isnt where you thought it was gonna be.

hardcoding is bad. avoid it if at all possible, but understand, that in some cases, it can be your best friend and reduce making something overly complex. if its built just for your company and needs a company ID or name that isnt going to change any time soon. it "can" be safe to use, vs creating some mish mash of code to extract it from a special table stashed in X database somewhere as 'reference' that some twit will mess up at the worst possible time.

as my "mentor" taught me: code with the thought of "do you want to debug that thing at 2:30am when it fails?" in mind.

then try to be straightforward and to the point. fancy schmancy logic can be a lot of fun to code and get running and give you a real sense of accomplishment...and then turn around and be a complete biotch to debug. even worse when its not you that has to debug it or conversely, have to debug something some old time assembler programmer built. they will curse you and your kin for an eternity (or you theirs) for making something too complicated to discover issues with, and ultimately correct.

so, no "real" advice...but just some survival tips for going forward.

K.I.S.S. rules the day.

rotsa ruck
__________________


a clear conscience is a sure sign of a fuzzy memory

Capt Jack is offline   Submit to Quotes Reply With Quote