Manifesto for code beacons use


A codebase is an ocean. It's vast, some parts are undiscovered and it's ever moving.

A wise sailor shall make good use of beacons to get his way around.

Management and career concerns should not be a motivation to place or search for a beacon. Quality, maintainability and ease of work should.


// HOWTO Authorization: Where the password is hashed

// RULE SPEC_AUTH_03: Users must re-authenticate after 30min of inactivity

// TEST SPEC_AUTH_03: Verifies session expiry triggers re-authentication


Codebeacons are specific comments that follow these conventions:

Searchability

One of the main goals of codebeacons is for them to be easily searchable when doing a full text search of a codebase repo(s). Codebeacons make a codebase more searchable.

No specific tooling shall be needed to use them. A simple grep, ctrl + shift + F or Notepad++ "Find in subfolders" must stay enough.

You then browse and search the full text search result for a beacon you are looking for.

Additional tooling can be handy, of course, but it shall never be essential, so beacons stay operational in lean environments like is a container in production.

Rarity

There must be only one occurrence of the same beacon in a codebase. Beware not to copy/paste a codebeacon when you copy/paste some code. Some tooling in an IDE/CI pipeline can help checking and enforcing that rule.

Codebeacons shall not get too numerous in a codebase. They must be well thought and carry real maintenance value. For example, if you are looking for a specific HOWTO beacon, you will typically make a full text search of the // HOWTO text through the code base. You will then have to browse that list. The shorter the list, the faster you will find the beacon you were looking for.

Also, keep in mind that finding out that a beacon is NOT present in a codebase should stay easy. A full text search of a codebeacon must be quickly browsable.

Placing a beacon

It's not easy to place a beacon. The sailor must stop, think and pay close attention.

Where is the best place to place it?

Here are some guidelines:

Ask yourself

Codebeacon types:

You can, of course, add your own types of beacons, like // PROMPT for example. Just make sure it does not get too complicated and that the whole thing stays easy, obvious and self-explaining to a new member of the team.

A codebeacon content description:

A codebeacon is made of 3 to 4 parts. For example:

// HOWTO Authorization: Where the password is hashed

  1. A codebeacon starts with a //   in a C like programming language. This would become -- //   in a SQL script, for example.
  2. Then, the HOWTO or RULE part is the beacon itself.
  3. Authorization : This third part, before ':', is optional. That lets you group related HOWTO beacons. On the other hand, for RULE and TEST beacons, that third part is a business rule identifier.
  4. "Where the password gets hashed". The last part is the beacon description itself. Keep it on one line only.

Setting well the third and fourth parts will make it easy to search and browse the result of a full codebase text search.


The sailor, placing code beacons along his journey, builds a map of the codebase that is well labeled and a great tool to set a course.