Difference between revisions of "Sanity 20141 - OOP344"

From CDOT Wiki
Jump to: navigation, search
(Created page with '== SANITY NOTE == You will be writing a number of classes and functions. Please remember to '''sanitize''' your code as you go along. ; What is code sanity? : The idea behind cod…')
 
(No difference)

Latest revision as of 15:18, 2 April 2014

SANITY NOTE

You will be writing a number of classes and functions. Please remember to sanitize your code as you go along.

What is code sanity?
The idea behind code sanity is to keep the code clean and the logic strong at all times. This has 2 main advantages.
  1. If your code is logically correct at all times then you can be sure that if there is a problem, it has been caused by the latest set of alterations.
  2. It makes debugging much much easier both for yourself and for anyone helping you
So how do I keep my code sane?
By following these simple steps:
  1. Keep the code nicely formatted at all times. This makes it easy to see the logical structure of your program at a glance and to follow the logic of it. Experienced programmers do NOT look for lines of code, they look for blocks denoted by indents. Train yourself to do the same.
    NOTE: If you are using an editor or environment that makes this hard for you, start by getting a better environment!
    Windows and visual studio are an excellent combination and provided for free by Seneca. On Linux, your options are netbeans and sublime. The debugging experience is simpler on Windows for our assignments however.
    Also note, on visual studio, you can have the editor automatically format your code nicely by pressing the following combinations in sequence:
    CTRL-K, CTRL-D
  2. Do not begin writing the next feature before the last feature is working! This is of paramount importance! By ensuring that your code is working (use the tests, specs, and your common sense!), you can save versions of your assignment at specific points in time and know that if a problem arises, it must be caused by your latest set of changes!
  3. Use a consistent naming convention for all member variables and another convention for local variables.
    This makes it easy for you and for anyone helping you to tell at a glance (ie WITHOUT looking at your header) which variables are local, member, etc...
    Too often I see conventions either not used, not used consistently, or mixed. Of the three cases, the third is the worst.
    Aim to ALWAYS use consistent naming conventions, whatever they may be.
    An easy set of conventions is as follows:
    Private/Protected Member Variable/Function
    _underscoreCamelCase
    Public Member Variable/Function
    regularCamelCase
    Local Variable/Function Parameter/Global Function
    regularCamelCase
    Public #Define (ie should be used by external code)
    SCREAMING_CAPS
    Private #Define (ie should only be internally used)
    _UNDERSCORE_SCREAMING_CAPS