Updating a rebased commit’s timestamp

When I work on a feature branch with Git, I like to do smaller commits in the branch. This allows me to rollback certain changes and to easily switch to another computer.

One thing that I don’t like about this approach is that when I do my final

git rebase -i

to squash all my commits into one, the timestamp of the final commit is the same as the first commit in the chain.

When I’ve been working for 3 days on something, I’d rather the timestamp be the same as if I had done one big commit in my branch, at the end, rather than one commit at the start and then nothing.

To fix this, I’ve found that I simply need to do:

git commit --amend --reset-author

and leave the information as is. This will update the last rebased commit to the current date and time.

Reblog: Disable Your Antivirus Software

I usually don’t (in fact I think this is my first time!) repost stuff from other blogs but I find this particularly interesting: Disable Your Antivirus Software.

Randomly generating a 2d RPG world

This is a compilation of all my posts about using procedural content generation to create a random 2d RPG world.

The first step is to create a heightmap. This randomly generated bitmap will serve as the basis of the world map. Then we can convert this heightmap to our world map. Finally we can generate some random names for our map (world name, city names, etc.)

Height map

Create the heightmap

Generating heightmaps using particle deposition

Using Gaussian blurring on heightmaps

A remote mountain cave.

Create the 2d world map

Creating a random 2d game world map

Creating a random 2d game world map, Part 2: Adding rivers and lakes

Creating a random 2d game world map, Part 3: Cities, caves and snow

I had used an open source implementation of the A* algorithm to add roads between cities. Sadly, I have never written about it. But here is a link to the relevant code:

Adding roads to our world map

A city next to a river.

Generating random names

Algorithm to generate random names

A better algorithm to generate random names

A snowy island.

Finally here is a link to a Github repository where I had implemented these algorithms:

Gameproject Repo

TODO comments best practices

// TODO: filter employees by role

The best use for TODO comments is when you are actively working on a change set, adding TODOs that will be replaced with actual code as you work. These TODOs will be removed before you commit to source control.

In this case you add a TODO, signifying an intention to return later on to complete the code.

Before committing code to source control, it’s always a good practice to review all your changes with a diff tool. This is the perfect time to scan for leftover TODOs in the code and implement them.

Another case for TODOs is for something that will truly be implemented in a later commit. Before leaving those kinds of TODOs in the code ask yourself if you shouldn’t rather create an issue in your issue tracker. Otherwise this second kind of TODOs tend to accumulate and pollute the source code. They experience the same kind of code rot as old commented out code does.

TODOs that you leave after a commit should be for changes that are small, implementable in the foreseeable future and relating to source code rather than business processes.

Before leaving those kinds of TODOs in the code ask yourself if you shouldn’t rather create an issue in your issue tracker.

On larger projects you tend to see TODO comments which are several years old. Just today I found one that source control indicated was 3 years old. The person responsible for the comment may not even be working here anymore. While reading this specific comment could give me a general idea of what should be accomplished it does not do so clearly enough that I can go do it. Or why for that matters it needs to be done. You tend to see these often enough.

This is similar to commented out code, where nobody knows why the code was commented out in the first place and thus leave it as it is thinking it may be important. As time goes by there is less and less chance of someone actually knowing why the code was commented out. So it stays there until someone is brave enough to just delete the useless comment (how can it be useful if no one knows why it’s commented out). Keeping track of old code is the source control’s job anyway.