Something I’ve come to notice during my career is that codebases are messy. I’m an extremely detailed person so this irks me very much. There are certain methods I use to ensure my code is as understandable as possible.

Function names are an example of this, I try to name my functions in a way that you’d understand what it does just by reading it. This means fn loadCats() is typically a closure that modifies an external element, whereas fn getCats() is a function that returns cats. I’m disgusted when I see a function like fn doStuff(...poorlyNamedParams). I get extremely frustrated parsing code and seeing something like this from someone who is supposedly my tech lead. This slows everyone down, including the author of the code. In a couple months, when the author tries to add a feature or fix a bug, they’ll have to dedicate a couple minutes solely to figuring out what the function does. That is far from ideal. To make matters even worse, it was a fn doStuff() was a closure.

Another interesting naming issue I have sometimes is in React. A .jsx/.tsx file should be in Pascal case. It’s ListItem.tsx not listItem.tsx. Components are also declared using Pascal case to its function ListItem() {} and not function listItem() {} and please… follow the naming conventions of the language you’re using. In Python, you can use snake case, but in TypeScript let’s keep it to the standards, please.

Another thing I vehemently (had to Google it) support is proper file structure. Some frameworks like NextJS, and Astro make this relatively simple since they have file-based routing. Of course, you have certain freedoms but for the most important things, there is an enforced structure. In Flutter my folder structure was always

application_name/
├── assets/
│   └── images/
│       ├── image_1.png
│       └── image_2.png
└── lib/
    ├── main.dart
    ├── app_root.dart
    ├── api/
    │   └── api.dart
    ├── constants/
    │   └── constants.dart
    ├── models/
    │   ├── animal.dart
    │   └── person.dart
    ├── screens/
    │   ├── animal/
    │   │   └── animal_screen.dart
    │   └── person/
    │       └── person_screen.dart
    ├── utils/
    │   ├── parse_animals.dart
    │   └── parse_persons.dart
    └── widgets/
        └── card.dart

I excluded some of the files for the sake of brevity (Googled it) but this is essentially the structure I stick to. I find it increases productivity by making it easy to find what you’re looking for. You know exactly where everything is.

Formatting is another issue I usually have, predominantly at one of my previous jobs. My tech lead wrote code and never formatted it. Every time the guy touched my code it would end up in a bad state both functionally and visually. Prettier is a gift from the heavens so please, I beg of you. Use Prettier or some other (team-approved) code formatter and format code on save. My muscle memory at this point is type, format, and save. I do this in rapid succession.

These are only some of the things that disturb me when going through code bases. Coming into existing codebases I typically just prepare myself for the horrors I will see in advance.

I’ve now reached the point at work where I review code as well so my hope is that I’ll drive the codebase in a more clean direction. While I hate being that annoying reviewer, I will flag pieces of code I think go against the accepted standards and I’m also not scared to give recommendations to my superiors, and colleagues. In my opinion, deviations from the standards have a snowball effect, one small issue, leads to many down the line so I’m here to stop that from happening.