Jul 1 2010

Why Your Code Sucks – Naming Conventions

I’ve seen a lot of poorly written and ugly looking code in my time. That’s not even considering the undocumented and uncommented code. We all know we should comment our code but how many of us do it consistently? I admit, when I’m in a coding frenzy, stopping to write comments just gets in the way of my thought process and can be distracting. I will however write a bunch of comments before I write the code, of the operations I think I need, in order to give me an outline of where I need to get to. For example:

// Get URL string for video file
// Load video file from URL request
// Load video file into video player
// Set up video player
// Play video

I may not know all the APIs to load and play the video just yet, but at least I’ve given myself an outline and as I fill in the code below each comment, I can see exactly what I’m doing and where I need to go.

Why Your Code Sucks

The point of this article is not to talk about comments, but how to avoid writing them in the first place within your functions and still be clear for everyone else, for the most part. This is your code:

newPlPt = crt2pl( nmc.x, nmc.y );

Not even a comment could concisely convey the meaning of that hideous statement. Instead, why not:

newPolarPoint = cartesianToPolar( newMediaContext.x, newMediaContext.y );

Well written code is self documenting. Let me restate that: if you can write code so that someone can jump to any point of that code and understand what’s going on at that point, read it like a sentence, and not have to decipher minute details like what each variable means, then you don’t have to comment most of your code.

There’s no reason you need to shorten the names in your code. Most programmers have never had file size limitations to deal with, so there’s no reason for it. Stop pretending you live in the 1960s and embrace nearly infinite file storage. To save keystrokes perhaps? Please, use a real IDE with code completion and stop doing stupid things like:

public function updateP( p:Player, d:MovieClip, b:MovieClip, t:Textfield);

Function Names

Also, because your functions are essentially actions, they need to reflect that in the name, so put a verb in the beginning of your function such as: getData(), setStatus(), enableWiFi(), hideControls(), handleGraphicException(), launchBall(), etc.

Class Variables

Get rid of the underscores in front of your class variables. For example: _dg; _myNumber;. All class variables should be private anyway, so why do you need that ridiculous convention? It’s a hold over from C where there was no “private” keyword, so you’re using it and you have no idea why.

Also, what’s with the “my” naming convention? You sound stupid when you have those: myInstanceName, myMovieClip, myGraphicsContext. Of course it’s yours, whose would it be, if not yours? If you’re programming with a colleague, do you refer to his variable references as yourInstanceName? Or hisVideoFileURL? Of course not. Don’t be that stupid; you’re reading too many stupid online tutorials by uncreative people who only code because they have nothing else better to do while living in their parent’s basement.

In the very least, be consistent with your naming conventions.

Hungarian vs. Polish notation

Depending on which language you’re coding in,  you may need to use a notation to help you with type casting. Let me rephrase that: if you’re using a loosely typed language, use Hungarian notation. You should probably use this with strongly typed languages anyway because with abstract types, you never know what you could get into and it’s just generally less confusing.

Hungarian Notation: vendorNameTextField or vendorName_txt

Polish Notation: txtVendorName or textFieldVendorName

Why not Polish notation? Not only is it ugly, but why would I sort on variable type instead of the variable name like I can do in Hungarian notation? The notation names come from how the speakers of those languages modify their verbs and nouns. To say: “My ball” in Hungarian is:  ”labám” where “labda” is the root word and the ‘m’ singifies a first person possessive. Hence the ending of the word shows the crucial information. It’s the opposite in Polish notation where the beginning of the word is modified. In the interest of full disclosure, I love the Polish, but I am Hungarian, but I promise that’s not why I prefer one over the other.

Final Thoughts

In the end, be consistent, be clear and spell out your variable and function names.


Jun 29 2010

Photos of the Week – Black and White

With the advances in digital photography and the cost of high quality cameras so low, everyone has become a photographer. However, few realize what it’s like to shoot  with film and fewer still, to shoot with actual black and white film.

The development process was the best part because you didn’t get to see your photos until you hung up your role of film on the drying line. Often times, you’d forget you even took some of your shots and be pleasantly surprised. There was no looking at your LCD screen after every shot, there was no deleting bad pics so that you could shoot more on your already full memory card. Different films yielded different colors, grain and style, which can now be duplicated in a computer, but it’ll never be the same. This week’s photo challenge was an attempt to force everyone to think about shooting for a purpose rather than for an edit in Photoshop later.

Disrepair

Disrepair

Branches

Branches

Yoga

Yoga


Jun 1 2010

Photos of the Week – After Hours

Sam and I started a photo project. It’s pretty simple: a theme and a set of photos (3-5) taken that week. This week’s theme was “After Hours.”

I always take photos, but rarely do I have time to post them. Since I have peer pressure now, it pushes me to go out, take some more photos with some thought behind it and finally post them.

Here’s Sam’s After Hours post.

A Tree Grows Through It

A Tree Grows Through It

Night Frame

Night Frame

Light Streaks on Fairfax

Light Streaks on Fairfax

Fairfax at Night

Fairfax at Night

A Sleeping Petunia

A Sleeping Petunia


Jul 31 2009

What’s Wrong with this Scuba Diver?

The diver in the photo below just cracked me up when I saw him. At first I only noticed his backup regulator hanging down and for the fact that he was almost literally walking on the sea floor. So, I took this snap shot and only later noticed that his tank strap is not secured either.

Bad Scuba Diver

The first thing you will notice about really bad scuba divers is loose gear flopping about. Not only does it look ridiculous, it’s also dangerous when they need to reach for their backup regulator and realize it’s floating behind them somewhere. Also, the back up regulator is suppose to be attached somewhere on the divers chest, so that if the dive buddy requires help, they can find and grab the other diver’s backup, unless of course it’s floating behind your dive buddy somewhere. In other words, don’t be this guy’s dive buddy.

Finally, don’t walk on the ocean floor. Not only is it bad style, it’s destructive and just plain stupid.


May 19 2009

Claytor Lake

After we dived at the river that morning I then headed to a day on the lake. The water was cold but I still had my wetsuit so I made good use of it there as well.

April Trip to Claytor Lake

It may look innocent, but it was freezing cold water

It may look innocent, but it was freezing cold water

 

Gabor up on the wake board

Gabor up on the wake board

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gabor is in a bit of pain after one of his falls

Gabor is in a bit of pain after one of his falls