Code Poetry

When you listen to good music, anything that you perceive is soothing or whatever qualifies music as good to you, you will feel a sense of satisfaction. Even though the music itself is not yours, you can always enjoy it. Ever read a piece of article which is crisp, to the point and yet drives the point in such an affirmative way that you are just happy that there are people who write without bull-shitting? Then there are the sculptures, the paintings and a whole lot of other arts which require an artist to create them but even more, people who appreciate the art itself. I am going to write about a form of art which is lost among a lot of people. The art of writing code, the cosmetics of it rather. Some of the key things to keep in mind if you want to write code that appears like poetry:

* One thing I think is the key to art is that there should be nothing redundant in the your work. It kills the genius behind the art itself. In the same way, there is no place for something which has no purpose in your code. Get rid of those variables and fields which you have because you think they may be useful in the future. Get rid of private/helper methods which are not used anymore. They are like random noise in a symphony.

* Claustrophobia is not something that only humans suffer from. You can't expect to write "The Prey" by Michael Crichton in 3 pages and expect people to read the whole thing. At the same time, I won't read a 10,000 page version of "The Prey" either. I enjoyed reading the 400-odd paged version thoroughly. The content mattered only after the spacing was properly. So, keep in mind to leave spaces as required by the conventions of the language that you are using. Like a space after an "if" and before the start of the parenthesis of the condition in Java, etc. When you write code, don't be prodigal in leaving white spaces and empty lines. They don't add value. They are a distraction. More often than not, people wonder as to why there is a new line and if they missed some logical separation marked by the demarcation. Follow the conventions all the time and be bold only when the situation calls for "dire" measures, and even that only when it comes to leaving a new line.

* Don't initialize local variables on one line and use it in the next line alone and nowhere else. You don't need such variables. For example:

int length = someList.size();
doSomething(length);

Here, there is no need for you to use 'length'. In fact, I would argue that the intent is much clearer when you write something like:

doSomething(someList.size());

Here you know, without an extra level on indirection that you are "doing something" with the size of the list. Traditionally, having a lot of variables was advised because function calls were very costly. But there is such an advancement in processors and compilers that there is virtually no difference between using a variable and a getter method of the variable. Given this, I would write something like this:

foreach(String name : getNames()) {
//whatever
}

This is a nice way to write "for each" statements without using local variables for the lists/arrays and you will appreciate it once you start using it.

* If you are programming, say in Java, make sure you choose an order in which you want to import stuff, so that it is consistent over the whole of your project. This keeps things neatly. For example, I would have all the bundled java classes be imported first. Then other stuff which are, say, javax stuff. Then I would import stuff which are from my project. This way when I, say, create a patch between my older version of a file and a newer version, I can be sure that if there is a change in the import, its because of a change in the code that affected it and not the order in which stuff are imported. In fact, I think this is a really important code cosmetic if you are using code versioning.

* Try avoiding the use of comments for private methods and variables and instead use a name which suggests what it does. The use of a good name is something that is emphasized the most by almost everyone but is something which is either not leveraged or abused beyond any use. Don't keep a constraint on how long the name should be. At the same time avoid using articles like 'a' and 'the' and try making the method sound like a sentence when it is read with the argument that is sent to it.

Most of the stuff here are in fact built into IDEs for the language you use. The options to do these may be obscure or obvious, based on the quality of the IDE itself. Its important to use them to write clean code.

These are some of the things that I think which makes a code appear clean and pure, like an art. I have seen some seasoned OO programmers who use these rules and many others and just to see them spew the code out is like watching someone paint. And the code itself reads like poetry.

Hacking

I know the media has hyped up the word "Hack" and "Hacker" so much and so bad that the true meaning of the words are lost among the masses. But what really ticks me off is that even a lot of people in the industry think I "broke" into a website or some network where I am not supposed to go and got my work done when I say, "I hacked my way around this stubborn problem". Illegally. Yeah, right, if I were a "Black Hat" I wouldn't dare write stuff with my identity so blatantly given away!

So, here's what Hacking means - HACK
And here's what Hacker means - HACKER
And the actual word which stands for "hacking" as people conceive is - CRACKER

I hope this makes a difference. Thank You.