Archive for Month: October 2015

Patterns: Document as you go

Ask any programmer what the most irritating part of programming is, and they’ll either say “debugging” or “documentation”. Admittedly, I am one of the rare exceptions (I dislike the “coding” part most, because it’s less about solving a problem than it is translating the solution), but I have a standard which removes the most irritating factors of documentation. Continue Reading…

Patterns: The 3-10 rule

Most programmers are, at least to some degree, familiar with Top-Down design principles. The 3-10 rule applies human nature to the top-down design rules, creating a substantially improved method for project generation. Continue Reading…

New Series: Patterns

Officially confirmed: starting tomorrow, we’ll be looking at patterns and behaviors that allow us to produce better, more reliable code at a higher rate. Continue Reading…

A Quick Look into my book process

While I get everything ready to move forward, here’s a quick look at how I’ve put my book(s) together. Continue Reading…

Planning is happening, so Open Q/A

I’m currently plotting out the next series (patterns and techniques for faster, cleaner, and more reliable code), so the rest of this week will be relatively light on content.

However, I want to hear from you guys. Blogging is something of a two-way street; the content improves when I can tailor it for my readership. Continue Reading…

Linux + C – Wrapup

Folks, we’ve pretty much reached the end of this series. Let’s take a look back on all the topics we’ve covered. Continue Reading…

Linux + C – Some other great tools

Well, we’ve pretty much run the gamut with Linux and C. However, there are a few other excellent tools you should know about.


Documenting code is a pain for most people. After months and months of diligent coding, they have to go back and create meaningful descriptions of all their library functions and how they operate.

I never have that problem, because I use Doxygen.

Doxygen is a program that translates specially-formatted comments into HTML documentation, complete with diagrams, hyperlinks, and other useful descriptors.

The format is fairly simple. Instead of using a single /*…*/ block, you use a /**…**/ block. Within this block, you can use the following tags:

  • @param – describe an input/output argument for the function
  • @brief – Write a brief description
  • @detail – Write a longer description
  • @return – describe the return values
  • @author – Put your name down, so people remember you’re the one who wrote the code
  • …and many more

So long as you continue to comment as you go, you will never deal with the documentation struggle that plagues so many.

Protip 1: All meaningful comments and debug logs are useful documentation. Don’t just throw them away when you’re done.

Protip 2: Document as you go. That way, when you come back to your code, you don’t have to re-discover how it works.


When we work on code, we make changes. Sometimes, it makes sense to track those changes, especially when multiple people are changing the code.

Git is a Linux utility that automates this code-versioning task. When you create a git directory, you create a tracking system which records all the “committed” changes between files.

The important things to remember with git are the basic functions:

  • Checkout – pull some code from a repository so only you can change it
  • Clone – Pull some code from a repository while allowing other people to change it
  • Commit – Tell your repository to save all the current files as the next version
  • Push – Send your committed files to a distant repository
  • Branch – Create a clone of a repository with a new name, which you will track separately
  • Diff – compare different versions of the code in your repository

It’s a great tool. For information on using this tool in the Open Source community, check out GitHub.

Note: the github site is a free, open-source repository host. It is not the official source of the git tool, nor do you need it to run git.


Sometimes you have two different versions of a file, and you want to know what the differences are.

Meld is a tool that takes two files or directories and prints out the differences between them in a well-designed GUI. It can also merge the files, generating one file with all the contents of the original input files.

Linux + C – Awk Example: Line Counter

Like most things, learning awk is much easier with examples. Today we’ll look at a simple awk script which counts lines of code based on their type.

The Code: linecount

The following code uses a lot of regular expressions to determine the nature of a line. There are three formats for these if statements:

if($0 ~ /REGEX/) {}

/REGEX/ {}

match($0, /REGEX/) {}

For simplicity, I am only using the first format.

Also, if we simply write the /REGEX/ without the braces, the default operation is /REGEX/ { print $0 }. I prefer to do it manually, but the option is there for you.

#! /bin/bash
echo ''
echo 'FILE            LINES    CODE    COMMENTS    ART'
echo '--------------------------------------------------------------'

for file in *; do
if [ -f $file ]; then
awk '
    BEGIN    {
        if(    $0 ~ /^$/         ||
            $0 ~ /^[\t]*;$/     ||
            $0 ~ /^[\t]*{$/     ||
            $0 ~ /^[\t]*}$/     ||
            $0 ~ /^[\t]*[(]$/        ||
            $0 ~ /^[\t]*[)]$/        ||
            $0 ~ /^[\t]*[};]$/    )
        else if($0 ~ /[//]+/)
        else if($0 ~ /[/*]/)
            while(!($0 ~ /[*/]/))
        printf("%16s\t%d\t%d\t%d\t\t%d\n", FILENAME, LINES, CODE, COMMENTS, ART);
' $file
echo ''

If you’re having trouble following the flow, this is what the program is doing:

  • If the line contains nothing or one of the “art” characters ( ) { } ; or };, classify it as “art” (meaningless, but makes the code prettier)
  • If the line contains //, classify that line as a comment
  • If the line contains /*, classify every line between that line and the line containing */ as a comment
  • Otherwise, classify the line as code

At the end, we print out the total number of lines and the breakdown of those lines.

Note: This code only works properly on C code. It won’t properly count, for example, scripts.

For more information and an excellent tutorial on all the facets of awk, check out the Grymoire (again).

Facebook Auto Publish Powered By :