Www.teratech.com 1/20 1 How to become a Guru Coder Michael Smith, TeraTech, Inc....

1 www.teratech.com 1/20

How to become a Guru Coder

Michael Smith, TeraTech, [email protected]://www.teratech.com

301-424-3903 x110

Copyright TeraTech 2004


Overview

What makes a smart coder? Brains or communications skills?

Does commenting matter to real programmers?

My Code is my Comment. What tips can you learn to become

a true programming guru?


Speaker InformationWho am I? Michael Smith President of TeraTech, Inc Rockville

MD http://www.teratech.com/ ttWebReportServer, CFXGraphicserver

MDCFUG, CFUN-03, Fusebox Conf Articles in CFDJ, Fusion Authority Winner CFDJ award Best Consulting


Programming Experience

22 years programming 7 years with ColdFusion 4 years with Fusebox Also work with SQL, JavaScript, HTML,

VB, Oracle, Access Teach one-on-one and custom classes On site and custom development Fusebox and Process Methodology


Does character matter?

Studies show that 85% of a programmers success is due to human factors rather than pure technical skills.


Humble

My brain can’t take in the whole program at once Use coding crutches Egoless programming Code reviews Ask for help if stuck > 15 minutes Murphy’s law Examples in comments Reference Change Tracker issue# and Desc Document algorithm used Rewrite complex code


Curious

How can I improve? Constantly learning Experiment Problem solving and planning skills Case studies - Programming Pearls,

alphablox.com, open source sourceforge.net RTFM and magazines, websites Have challenging projects Google skills


Honesty

I don’t know I was wrong Fix bugs rather than covering up Understand code before you run it True status reports – including “bad” news Stand by accurate estimates


Communication skills

WORM code, not WMRO code Write code for humans to read, not for computer to

run Clear emails Use the phone

correct understanding Get extra information

Listen to upsets, allow let off steam Remember the user – actors, photo, useability

testing


Coding conventions

Save having to think about that part of code Variable naming Database naming Correct spelling propagates Indenting Case Avoid poor constructs Scope variables, avoid public http://www.cfug-md.org/articles.cfm#code


Coding conventions

Save having to think about that part of code

Variable naming Indenting

Clarifies meaning Case Avoid poor constructshttp://www.cfug-md.org/articles.cfm#code


Lazy

Write smart code instead of repetition of code Write or use a tool instead of repeating steps by hand Macros in your code editor Use a pre-built tool instead of reinventing the wheel Write less code – copy existing code, searchable

library of code Using template, existing document Consistent look between programmers and projects


Prioritize

Plan before you Code before you Debug

Think before you Document before you Code before you Run

Test as you go


Not as important

Persistence – pigheaded Experience – is 10 years of experience or

10 x 1 year’s experience? Jolt programming – all nighters Code disappear can be good – chance to

rewrite Avoid tweaking for ever for perfect code


Good habits

Code and understand before running End loops before coding the “filling” Don’t go long with code “broken” Plan before coding Figure out how you will test code before coding Take a break; sleep on problems “Telephone” review of problem to a buddy Write algorithm on whiteboard – diagram Comment to relate distant open and close tags


Reduce complexity

Avoid global data Short routines, few parameters Limited nesting Data driven vs complex logic Named constants – rather than magic numbers Descriptive names – variable, database, files, short,

no weird characters Comment – see below rather than break up code Don’t make code or comments horizontally, printable


Modularize to simplify

Hide details – black box De-Couple routines Cohesion – do one thing well Test parameters


Code for humans to read

WORM code is easier to: Understand Review Less errors Faster to debug Easier to modify Faster to develop overall

Sets a good habit


Defensive coding

If it can go wrong it will go wrong Check parameters exist and data type Throw errors if assumptions not met Always code the ELSE part of IF


Debugging

If you can prove your algorithm must work It is less effort to Debug.

Test Parameters at and beyond their limits. (Some tests must show a failure)

Keep it Simple, Stupid (Kiss) If you can’t remember what it does, how can it be

maintained? Use debug mode variable to get extra info, stop page

execution, save to file, email to self Take a break, take different approach Use multiple catches


Resouces

“Code Complete” – Steve McConnell “The Mythical Man-Month” by Frederick

Brooks “Peopleware” by Tom Demarco, et al


Questions?

Email me at

[email protected]

Www.teratech.com 1/20 1 How to become a Guru Coder Michael Smith, TeraTech, Inc....

Documents

Transcript of Www.teratech.com 1/20 1 How to become a Guru Coder Michael Smith, TeraTech, Inc....