Complete Coding

The Ten Commandments for C++ Programmers

On July 22nd, 2010 by Kevin | 2 Comments | Posted in programming

From the book “Practical C++ Programming” by Steve Oualline, The Ten Commandments for C++ Programmers written by Phin Straite.

1. Thou shalt not rely on the compiler default methods for construction, destruction, copy construction, or assignment for any but the simplest of classes. Thou shalt forget these “big four” methods for any nontrivial class.

2. Thou shalt declare and define thy destructor as virtual such that others may become heir to the fruits of your labors.

3. Thou shalt not violate the “is-a” rule by abusing the inheritance mechanism for thine own twisted perversions.

4. Thou shalt not rely on any implementation-dependent behavior of a compiler, operating system, or hardware environment, lest thy code be forever caged within that dungeon.

5. Thou shalt not augment the interface of a class at the lowest level without most prudent deliberation. Such ill-begotten practices imprison thy clients unjustly into thy classes and create unrest when code maintenance and extension are required.

6. Thou shalt restrict thy friendship to truly worthy contemporaries. Beware, for thou art exposing thyself rudely as from a trenchcoat.

7. Thou shalt not abuse thy implementation data by making it public or static except in the rarest of circumstances. Thy data are thine own; share it not with others.

8. Thou shalt not suffer dangling pointers or references to be harbored within thy objects. They are nefarious and precarious agents of random and wanton destruction.

9. Thou shalt make use of available class libraries as conscientiously as possible. Code reuse, not just thine own but that of thy clients as well, is the Holy Grail of OO.

10. Thou shalt forever forswear the use of the vile printf/scanf, rather favoring the flowing streams. Cast off thy vile C cloak and partake of the wondrous fruit of flexible and extensible I/O.

Today’s Read: Four Ways To A Practical Code Review

On July 20th, 2010 by Kevin | No Comments | Posted in development

As per the definition of Wikipedia,

Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

In this article, Jason Cohen mentions that there exists a formalized system of code review developed by Micheal Fagan at IBM in the mid-1970s. However he points out that the software development process has come a long way since then and we can have process and metrics and measurement and improvement and happy developers all at the same time. The way to achieve this is by using a lightweight code review.

There are four types of lightweight code review techniques:

1) Over-the-shoulder: One developer looks over the author’s shoulder as the latter walks through the code.
This is the code review technique that we use in our organization and that I am familiar with. Once the implementation has reached a level of completion, we initiate such an over-the-shoulder code review process. One of the experienced peers working on the project acts as the reviewer and sits alongside the developer. The developer walksthrough the code implementation explaining why and how the implementation has been done. The reviewer can interrupt the review process to ask any queries and point out discrepancies in the implementation. Small changes can be fixed by the developer during the review process. Larger changes can be taken offline. Once the code review is complete, the developer can check in the changes to the SCM system.

2) Email pass-around: The author (or SCM system) emails code to reviewers.
This is the second-most common form of lightweight code review, and the technique preferred by most open-source projects. Here, whole files or changes are packaged up by the author and sent to reviewers via email. Reviewers examine the files, ask questions and discuss with the author and other developers, and suggest changes.

3) Pair Programming: Two authors develop code together at the same workstation.
Pair-programming is two developers writing code at a single workstation with only one developer typing at a time and continuous free-form discussion and review.

4) Tool-assisted: Authors and reviewers use specialized tools designed for peer code review.
This refers to any process where specialized tools are used in all aspects of the review: collecting files, transmitting and displaying files, commentary, and defects among all participants, collecting metrics, and giving product managers and administrators some control over the workflow.

The complete article by Jason Cohen can be found at: Four ways to a Practical Code Review.

The History Of Carriage Return Line Feed

On July 18th, 2010 by Kevin | No Comments | Posted in programming

Most of us developers (especially Windows developers) wonder why an end-of-line is represented by <carriage return><line feed> in Windows text files. What does <carriage return> or <line feed> exactly mean?

In the early stages before computers, there existed a device known as the TeleType. The TeleType contained a keyboard, printer, and paper tape reader/punch. It could transmit messages over telephones using a modem at a rate of 10 characters per second.

TeleType

But TeleType had a problem. It took 0.2 seconds to move the printhead from the right side to the left. 0.2 seconds is two character times. If a second character came while the printhead was in the middle of a return, that character was lost.

The TeleType people solved this problem by making end-of-line two characters: <carriage return> to position the printhead at the left margin, and <line feed> to move the paper up one line. That way the <line feed> “printed” whilethe printhead was racing back to the left margin.

When the early computers came out, some designers realized that using two characters for end-of-line wasted storage. Some picked <line feed> for their end-of-line, and some chose <carriage return>. Some of the die-hards stayed with the two-character sequence.

Unix uses <line feed> for end-of-line. The newline character \n is code 0xA (LF or <line feed>). MS-DOS/Windows uses the two characters <carriage return><line feed>. So if you are transferring text files from a Unix machine to Windows, you have to use some conversion utility eg. unix2dos for stripping the <carriage return> character from the files.

Further reading:
How do I convert between Unix and Windows text files?
Newline Character