Quotes and Notes from 'Becoming a Better Programmer' - Chapters 9-10

From O'Reilly e-book:
Becoming a Better Programmer by Pete Goodliffe

Chapter 9 - Expect the Unexpected

Any function you call may not work as you expect.
• If you are lucky, it will return an error code to signal this. (p.69)

p.70:

•  understand basic concurrency principles
• Understand mechanisms to reliably and quickly pass messages between thread contexts without introducing race conditions or blocking the threads unnecessarily
•  Shutdown:
• how to bring the code to a graceful halt without leaking resources, locking up, or crashing
• especially hard in a multithreaded system
• don't leave one object attempting to use or return to another that has been deleted

Chapter 10 - Bug Hunting

• Lay Traps: Add assertions or tests to verify the system invariants—the facts that must hold for the state to be correct. (p.78)
• Binary Chop: (p.78)
  
• Work out the start of a chain of events.
• Work out the end
• Check middle point
• if good, then start to middle is good, so check midpoint of here to end
• if bad, then check midpoint of start to this point
• Software Archaeology
• Look thru your version control to find the last time this bug didn't exist
• Binary chop through time to find where bug was introduced
• Use a code coverage tool to inspect how much of your code is actually covered by tests. (p.79)
• Once you find the bug:
• Write a simple test that demonstrates the bug.
• Add it to the test suite before you fix the code.
• Use the test to:
• prove bug is fixed
• test to prevent bug from reoccurring
•  Analyze/look for related bugs
• Are there more bugs in the section where you found this one?
• Was bug in a repeated code pattern that's used elsewhere?
• Note in which parts of the code you're finding more bugs.
• Part of code that's used most often?
• Weakness in that particular section of the software? 
• Non-Reproducible Bugs
• Keep records that may eventually help you come up with theories you can test to possibly find the cause.
• Add more assertions and log statements -- preferably into your beta or release builds.
• Automate a test farm to run long-running soak tests.
• Common situations leading to hard-to-reproduce bugs:
• Threads
• "Heisenbugs" - disappear when you add log statements
• Network interacation
• Speed to access database, disk, other storage can vary
• Memory corruption
• Global variables

Quotes and Notes from 'Becoming a Better Programmer' - Chapters 2-8

From O'Reilly e-book:
Becoming a Better Programmer by Pete Goodliffe

Chapter 2

• KEY ➤ Remember who you’re writing code for: other people. (p.9)
• page 10:

Some programmers like to present banner comments in pretty ASCII-art boxes:
/**************************************************
* This is a pretty comment. *
* Note that there are asterisks on the *
* righthand side of the box. Wow; it looks neat. *
* Hope I never have to fix this tiypo. *
**************************************************/

...Frankly, this is a sadistic presentation style.

• Also on p.10, he says to write code as you would prose. "Functions are akin to chapters."
• Within the chapters, related lines of code are equivalent to paragraphs.
• Insert blank lines only between these conceptual paragraphs, not within them
• Don't have too many of these "paragraphs" per function

• If you clean up code, make that a separate commit from any changes to the code's behavior.
  KEY ➤ Never alter presentation and behaviour at the same time. Make
  them separate version-controlled changes. (p.14)

Chapter 3

• (p.18) There are many reasons why unnecessary code is the root of all evil...
• Writing a fresh line of code is the birth of a little life form.
• ...
• Code harbours bugs. The more code you have, the more places there are for bugs
  to hide.
• Refactoring (p.20) 
• A refactor is only a refactor if it is a transformation of the source code, preserving behaviour.
•  the DRY principle: Don’t Repeat Yourself!
• ...factoring similar code into a shared function introduces tight coupling...
  They both now rely on a shared interface;...
  —so DRY your code responsibly! (p.21)
• Dead code is code that is never run, that can never be reached...
• Tell your code to get a life, or get lost. (p.23)
• The code itself says what and how. A comment should explain why..(p.24)
• Do not remove code by commenting it out. (p.24)
• Remove code completely. 
• You can always get it back afterwards from your source control
  system.

Chapter 4

• YAGNI = You Aren’t Gonna Need It: (p.29)
• Don't write..code you think is going to be needed in future versions. 
• Don’t write it now if you don’t need it now. 
• Much "debug" code is necrotic...unsightly scaffolding that hides the beautiful architecture underneath. (p.31)
• It is harder to refactor, simplify, or optimise your program when it is bogged down
  by zombie code. (p.32)
• Don’t add “minor”features that you think are interesting, but no one has asked for. They’ll be easy enough to add later, if they are required. Even if it seems like a good idea. Don’t do it. (p.33)  That one is hard to resist. :^)

Chapter 6

• ...try adding a single, one-line, failing test. Does the test suite immediately fail? This smoke test proves that the tests are not actively being ignored. (p.50)
  

Chapter 7

• I know I shouldn’t moan, but sometimes I swear that programmers shouldn’t be allowed
  to type the word thread without first obtaining a license to wield such a dangerous
  weapon. (p.56)
• ...if it has been working adequately for years without tinkering, it is probably inappropriate to “tidy it up” now, especially if you’re unlikely to need to make many more changes in the future. (p.58) 
• KEY ➤ Make code changes slowly, and carefully. Make one change at a time. (p.58)
• ...the unreadable mess of special cases might be like that for a reason. Each bodge and code hack encodes an important piece of functionality that has been uncovered through bitter
  experience. Ignore these subtle behaviours at your peril. (p.59)
• The effective programmer does not only deal well with the bad code, but also with the people that wrote it. (p.60)
• “refactored the code to look neater.” -> “refactored code back to working.” (p.60)

Chapter 8: 

• Don't ignore:
• Return codes -  e.g. printf
• Side effects - e.g. errno - which is a mess when code is threaded
• Exceptions

try
{
    // ...do something...
}
catch (...) {} // ignore errors
The saving grace of this awful construct is that it highlights the fact you’re doing
something morally dubious. (p.64)

• Understand your language’s idioms and requirements for effective exception use. (p.65)

Using Workflowy to dissect a task into do-able bits

When you're finding yourself having trouble getting started with something on your to-do list, start subcategories under the main task, and include in it all the questions and obstacles you see, and then the sub-task questions and obstacles and tasks that exist under them. Keep creating the sub-tasks until you see the concrete things that you can do first. 

Create free lists like this at  https://workflowy.com/

python: Nonintuitive ELSE after FOR or WHILE

When I first saw an else clause after a for loop, I concluded that those were the steps to run if the condition inside the loop was never true-- that is, either you enter the loop or you do its else.
Wrong: Those are the steps to run if you exit the loop without a break statement. 

A better label would be NO_BREAK, but I understand not wanting to add keywords to the language. 

Test: Are the else steps executed when the loop is never entered?

for thing in ['abc','','tobreak','ok']:
    print "\nvertical [%s]" % thing
    for c in thing:
        print c
        if c=='r':
            break
    else:
        print "No r in [%s]" % thing
else:
    print "\nthat's all"

output

vertical [abc]
a
b
c
No r in [abc]

vertical []
No r in []

vertical [tobreak]
t
o
b
r

vertical [ok]
o
k
No r in [ok]

that's all

Process finished with exit code 0


SVN - unversioned contents in SVN-renamed directory

I noticed this using Tortoise SVN in Windows:

If a directory is renamed under SVN and you then update its parent directory, your current directory will be deleted, and a new version of the directory, with the new name, and all of its contents, will be downloaded back to your checked-out version of the parent directory.

This can be a real pain when there are a lot of big files that are deleted and then downloaded back again. Enough to rant about, and want a better way of implementing SVN Rename, but that's not the subject of this blog entry. The subject of this blog entry is:

If you have unversioned items in a directory that is in SVN, and you (or someone else) changes the name of that directory in SVN, then after the commit or update, SVN will leave a copy of the directory with the old name, containing the unversioned contents.

That is:

1. I have a directory: Dir-v, which contains versioned file File-v and unversioned file File-u.
2. Someone changes the directory name to newDir-v and commits the change.
3. I update Dir-v's parent directory.
4. I now have two directories: 
1. versioned newDir-v containing File-v 
• in Tortoise/Windows you'll see a green check mark on their icons
2. unversioned Dir-v containing unversioned File-u
•  in Tortoise/Windows, you'll see a blue question mark on their icons
5. I can delete the unversioned Dir-v after deciding what I want to do about File-u.

Why do I have unversioned files in my SVN directories? Well, there are some local files that I want to be categorized with, and able to find when I'm looking at other files that are in the SVN, but I don't think the other people in the project want these files in their copy of the structure. Is that bad?

python: simple timestamp string

For attaching a relatively unique string to a file name:

import time
>>> str(time.time()).replace('.','')[-8:]
'29107263'

python: scope error - from Amir Rachum's newbie mistakes, Part 2

Slightly rephrasing the examples in http://blog.amir.rachum.com/blog/2013/07/09/python-common-newbie-mistakes-part-2/: 
>>> bar=42
>>> bar
42
>>> def foo():
...     print bar
...   
>>> foo()
42
>>> def foo():
...     print bar
...     bar=2
...   
>>> bar
42
>>> foo()
Traceback (most recent call last):
  File "< input >", line 1, in
  File "< input >", line 2, in foo
UnboundLocalError: local variable 'bar' referenced before assignment
>>> def foo():
...     global bar
...     print bar
...     bar=14
...   
>>> bar
42
>>> foo()
42
>>> bar
14

MS Word - Copying a format from one picture to another

I'm creating a document with many small screenshots. I surrounded one of them with a thick blue line, and wanted to do the same for the others. It's very tiresome to right-click, select Format Picture, select Line Style, select Line Color over and over, so I googled: The search for "ms word copy picture format line" led me to support.office.com, specifically: Use the Format Painter which was a feature of which I was unaware.

Apparently, the little whisk broom icon named "Format Painter" on the top-left section of the toolbar can be used to copy formatting from one object to another. I don't know why they didn't name it "Copy Format"--then I would have guessed at its function.

Of course, now that I know that it is something, I mouse over it and see a Tooltip telling me about it, but there are so many dang things associated with MS Word that one doesn't have time to learn or much occasion to use... Anyway..

To use it:

1. Select the object whose format you want to copy.
2. Double-click on the Format Painter paintbrush.
3. Move the cursor back onto your document: the cursor becomes a paint-brush.
4. Click on as many target objects to which you want to copy the format.
5. Click "Escape" to stop copying. The cursor returns to normal.

python: pathlist test with numbered output & avoiding empty values

Here's the code in the previous post with a few enhancements:

import os

def test_path(in_path,sep=';'):
    pl=in_path.split(sep)

    there=[]
    not_there=[]
    for t in pl:
        if len(t) > 1:
            if os.path.isfile(t):
                there.append(t)
            else:
                not_there.append(t)

    print "These exist"
    for i,t in enumerate(there):
        print "%d  %s" % (i+1,t)

    print "\nThese are missing:"
    for i, t in enumerate(not_there):
        print "%d  %s" % (i+1,t)

python: simple method to test pathlist

I'm converting a Window's batch script to run on my system. One of its lines defines a long semicolon-separated path list. I started to check them one-by-one, then realized there was a simpler way:

import os

def test_path(in_path,sep=';'):
    pl=in_path.split(sep)

    there=[]
    not_there=[]
    for t in pl:
        if os.path.isfile(t):
            there.append(t)
        else:
            not_there.append(t)

    print "These exist"
    for t in there:
        print t

    print "\nThese are missing:"
    for t in not_there:
        print t