Prettier or not: you decide!

Here is a piece of TypeScript code before and after using prettier. IMHO: if you want to ruin your code in a second, use prettier! I did not even use very long lines of code, and set the limit to the recommended 80 characters!

BEFORE:

AFTER:

If your programmers cannot write code properly/dev-friendly, you have more serious issues than linters, code formatters and their settings!

If you want to write code in a dictatorship, continue using prettier!

Writing code is art, like painting on canvas: until we see computers / robots painting like humans, I will not let my team’s code be ruined by code formatters!

https://www.npmjs.com/package/prettier

To me, it’s just another unnecessary piece of over-engineered tool.

Think about it: it is like someone always stopping you while you are talking, and correcting everything you say.

People should spend their time on better things, life is short :)))

You can agree with your team and possibly follow industry standards as much as possible and document it – not a long document – like ESLint with “recommended” settings. ESLint can give you warnings that you may choose to act on them. Readable code is much more important because it reduces time required to onboard new members, transfer knowledge, maintain code and fix bugs. Any waste of developer’s time is additional cost for the company – we can avoid easily. At the moment, IMHO, tools like prettier are not good enough.

https://www.npmjs.com/package/eslint

Another excuse is consistency which is great but there should be room for exceptions as well esp. when we are integrating multiple systems with different styles, and we could write less code and comprehensible code in one function just by avoiding input/output adaptation – that adaptation is usually excused because we do not like PascalCase, camelCase or lower_snake_case etc. BTW, I do not twitch when I see lines of code which has both styles :))) Input/Output adaptation will also degrade system performance.

I think this topic (Writing Beautiful Code) is one of the important aspects to consider, if one wants to increase his/her “indispensability” score in the company. (Please note that I have worked for companies where people do not share their knowledge.)

We also know that code linters and formatters will not rename our variables, constants, functions and models, yet. They will not make very long and chained expressions shorter and more meaningful. But if we write code that is easy to read and understand, everyone will enjoy their job and excel at it. Even the code will not require too many comments.

Here is a quick one:

if (calculateAge(new Date(u.dob)) > 18 && u.ccode === 'GB' && (u.status === 'pending') && (u.tac === 1)) {
  u.status = 'active';
  save(u);
}

vs

if (user.canRegister()) user.register(); // much simpler



class User {
  canRegister(): boolean {
    return this.isAccountPending()
      && this.hasAgreedTermsAndConditions()
      && this.isLegallyAdult();
  }
  register(): boolean {
    this.status = UserStatusEnum.Active;
    return this.db.update(this);
  }
  isAccountPending(): boolean {
    return this.status === UserStatusEnum.Pending;
  }
  hasAgreedTermsAndConditions(): boolean {
    return this.tac !== 0;
  }
  age(): number {
    return calculateAge(new Date(this.dob));
  }
  countryCode(): string {
    return this.ccode;
  }
  isLegallyAdult(): boolean {
    return this.age() >= countryAgeLimit[this.countryCode()];
  }
}
const countryAgeLimit = {
  GB: 18,
}
enum UserStatusEnum {
  Pending,
  Active,
}
function calculateAge(dob: Date): number {
  const diffInMs  = Date.now() - dob.getTime();
  const ageAsDate = new Date(diffInMs);
  return Math.abs(ageAsDate.getUTCFullYear() - 1970);
}

I hope that helps.

Enjoy coding! 🙂

Tags: , ,
Categories: