{"id":659,"date":"2013-07-06T07:21:41","date_gmt":"2013-07-06T05:21:41","guid":{"rendered":"http:\/\/antoine.wojdyla.free.fr\/blog\/?p=659"},"modified":"2013-12-08T05:01:20","modified_gmt":"2013-12-08T03:01:20","slug":"lab-resources-ii-software-coding","status":"publish","type":"post","link":"http:\/\/antoine.wojdyla.fr\/blog\/2013\/07\/06\/lab-resources-ii-software-coding\/","title":{"rendered":"Lab resources II- Software coding"},"content":{"rendered":"

Sometimes, I wonder “WWFD?”
\nHere’s a collection of ideas and resources for scientific programming.<\/p>\n

\"\"<\/a><\/p>\n

Steps in programming…<\/p>\n<\/div>\n


\nThe best personal advice I can give you is : take your time to design (spending 10 minutes can save you a week).
\nAlso, do not hesitate to spend time on thinking of how to visualize your data <\/a>: it makes a huge difference, for you and for others !<\/p>For the rest, follow the list !<\/p>\n

Coding best practice<\/h1>\n
    \n
  1. Commenting & documentation (design and purpose, not mechanics)\n
      \n
    1. Consistent indentation (do not mix space and tabs)<\/li>\n
    2. Avoid obvious comments<\/li>\n<\/ol>\n<\/li>\n
    3. Consistent naming scheme (define it!)\n
        \n
      1. Minimize the use of abbreviations<\/li>\n
      2. Consistent temporary names<\/li>\n
      3. Avoid homonyms<\/li>\n
      4. Pair antonym procedures (open\/close, etc.)<\/li>\n<\/ol>\n<\/li>\n
      5. Keep your code simple (The \u201c20 lines\u201d rule)\n
          \n
        1. Avoid deep nesting (hard to read)<\/li>\n
        2. Limit line length (hard to read & viewer dependancy)<\/li>\n
        3. File and folder organization<\/li>\n
        4. Don\u2019t repeat yourself<\/li>\n
        5. Code refactoring<\/li>\n
        6. Code grouping<\/li>\n
        7. Use globals sparingly<\/li>\n<\/ol>\n<\/li>\n
        8. Write programs for people, not computers\n
            \n
          1. Do you have testers\/hallway usability testing?<\/li>\n
          2. Provide useful error messages<\/li>\n<\/ol>\n<\/li>\n
          3. Have a high level design or a low level design and Function specification and proof of concepts\n
              \n
            1. Push interface up and implementation down\n
                \n
              1. i.\u00a0\u00a0\u00a0\u00a0\u00a0 Level 1 (high): accept user input<\/li>\n
              2. ii.\u00a0\u00a0\u00a0\u00a0\u00a0 Level 2: taint check and normalize user input, and check for errors<\/li>\n
              3. iii.\u00a0\u00a0\u00a0\u00a0\u00a0 Level 3: process user input according to business logic<\/li>\n
              4. iv.\u00a0\u00a0\u00a0\u00a0\u00a0 Level 4 (low): store data<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n
              5. Separation of code and data\n
                  \n
                1. Wrap built-in functions and third-party library functions with your own wrapper functions<\/li>\n
                2. Don\u2019t assume output formats<\/li>\n
                3. Internal data should be in native format<\/li>\n
                4. Operate on objects, not data structure<\/li>\n<\/ol>\n<\/li>\n
                5. Test returned status for error conditions\n
                    \n
                  1. Recover or fail \u201cgracefully\u201d : Robust programs should report an error message<\/li>\n<\/ol>\n<\/li>\n
                  2. \u201cPremature optimization is the root of evil<\/em>\u201d (Optimize software only after it works correctly)<\/li>\n
                  3. Never rewrite code from scratch<\/li>\n<\/ol>

                    I found this list on the internet, less formal but still very interesting :<\/p>\n