Programming

Five Quick Check-In Guidelines

2011-01-17 1 minute read

If you work in a source controlled environment, these are the minimal guidelines that you’ll have to stick to for making your teammates’ lives a bit easier.

1. Don’t Check-In Broken Code: More than often, you’ll pull down the latest version of a project from your repository only to find that the code won’t build. Please, don’t check-in code to the main project that doesn’t compile, even if you intend to pick up the slack the next day. However:
2. Don’t Go Home Without a Check-In: Even though you shouldn’t check-in your broken code to the main branch, many source control systems have a way to branch a user’s changes and merge them back later. If you’re using Team Foundation Server, take a look at Shelve Sets.
3. Use Check-In Comments: Always leave a descriptive comment of the work you’ve done when your check-in. Your teammates weren’t hired to analyze undocumented code, so that 500-line change across multiple files better have a comment.
4. Check-In Association: If your source control system allows this type of integration, associate your check-in with a work item, bug, or help-desk ticket. If it does not, at least make a reference to the work item’s identifier in the comment section.
5. Use Check-In Policies: Use check-in policies to ensure that all of the above things aren’t impeding your build if your source control system supports them. These policies make your life easier and disallow sneaky developers from checking-in their broken spaghetti code.

Share any tips you may have!

Hungarian Notation: What to do?

2009-01-21 1 minute read

Edit: FYI, by Hungarian notation, I mean Systems Hungarian such as bIsSucky.

It seems I’m in some kind of pickle. For some reason, two of the programmers at the company I work for still use Hungarian notation.

In case you don’t know what that is, in short: Hungarian notation prefixes an abbreviation of either the data type or purpose of the variable to its name. For example, Microsoft’s WINAPI still uses it, hence we have things such as hInstance, nShow, szCompany, etc. So it’s quite ugly and confusing to the programmer.

Yet these two programmers still cling to their old ways and refuse to give up on this ancient method. Even in VB.NET. One of these programmers happens to be Joe the Programmer mentioned before, go figure.

I was asked by one of them “Why not use Hungarian notation?” In case you dind’t know, dear reader, the name of the variable should give away the data type, use UpperCamelCase and logic for your naming conventions. Turns out, UpperCamelCase is a programming convention in this company, so why we were arguing, I don’t know. Now if only logic were a convention, we’d be set.

But it was like pissing against the wind as neither them nor I were persuaded in the end. How would you persuade a person to switch to a different methodology? By them using Hungarian notation, people who will eventually take over their source code will want to shoot themselves.

Programmer’s Block

2007-05-23 less than 1 minute read

I guess writers have this, but now I have it with coming up with new programs. I just can’t think of anything. I’ve been wasting my time reading many programming books on Agile, Design Concepts etc. but that didn’t give me any ideas either. Some knowledge, yes, but inspiration, no.

Bah.