As I return to programming in Linux again I have begun to regain my previously acquired tools and knowledge. Because of this, I have decided to write this post describing how to setup a basic configuration file for the vi editor. This file will prevent the headaches of having to reset all of your settings every time you load a vi session.

Make a new file in your home directory called .exrc. What will I use to edit this file…vi of course!
% cd /home/craig
% vi .exrc

Inside the file is where you write all of your set commands that you would normally write at the start of a vi session.
The following are settings that I find I use often.
# number - Displays line numbers
# autoindent - Indents the left margin of new lines by the indent of the previous line
# tabstop - Sets the number of spaces for each tab on the screen.
# wrapmargin - Starts a new line before reaching the right margin. This occurs when the last word is less then the set number of characters./

My configuration file looks like the following.
:set wrapmargin=15
:set number
:set autoindent
:set tabstop=5

Save and restart vi, your changes should now be visible in your editor. Enjoy.

While reading Joe Stump’s blog, I came across a link to this interesting article on the psychology of programmers. It talks about how programmers resemble that of artists more then scientists and explains how to gain the most out of your development team by understanding the psyche of the programmer and how we work. I found it a good read, check it out.

http://www.devx.com/devx/editorial/11659

After reading this article Men Write Code from Mars, Women Write More Helpful Code from Venus I find myself thinking I write code more like the description of code written by women. I tend to be a style junkie always concerned with writing very clean and smooth running code that can easily be read and understood later. Writing code with a hidden intent and in a cryptic way just doesn’t sit right with me. I find it to produce more buggy code, harder code to debug, and is not visually elegant. I am definitely not isolated to this issue however because I have worked and seen many people with this approach to coding. I think for most it is just an ego issue and is thought to bring job security to oneself.

Although commenting can benefit others understanding of your code, over use of commenting can also become a bad thing. To much commenting separates and spaces the code to the point where it becomes hard to understand its overall intent quickly. This is partially due to the fact that your scrolling up and down and loosing your placing constantly. I prefer to fit an entire section of code on my screen where I can walk through it and attain its flow and intent myself without leaping over comments. If I feel a routine needs heavy commenting then I will comment the routine at its beginning, and provide an overall summary of what is to come.

In conclusion I guess what I am trying to get across is that I feel it is better to write code that describes itself and its general purpose by its structure and style then to write sloppy code and comment the hell out of it. Steve Yegge writes a brilliant article on this subject appropriately named Portrait of a n00b.

If you are interested in reading more into writing style focused code, I highly recommend the book The Practice of Programming. Written by Brian Kernighan and Rob Pike you can be sure that there is a lot to gain from it and I personally have found it an excellent read.