Should I use type prefixes or suffixes?
Sunday, July 5, 2020
Should I use type prefixes or suffixes?
The short answer in my opinion is "no". The reasons include: their noisy, types changes, IDEs are smart, and this can often lead to inconsistencies and reduced readability.
Types Change
Whether you are programming using a language that uses a dynamic or static type system, using type prefixes or suffixes can lead to a practice of naming variables based on the current type, which may change over time, especially as your code is maintained, and, potentially refactored.
Noisy
Whenever I am in a code base that uses either type prefixes or suffixes it feels a bit noisy to me. This in turn reduces the readability of the code.
Inconsistency
Consistency leads to code that is more maintainable and readable. Whether we are the sole programmer in a project, or we part of a team, or even more so, if we are part of a large organization, consistent naming conventions are critical. If one team, or one team member, uses type prefixes or suffixes, and others do not, moving around the code base, or organizational teams, is going to be deterred.
IDEs are Smart
Most of us are using some sort of code editor or IDE that has deep code introspection capabilities that reduces the need for typing information to be presented to a developer along with the variable name. Further, code intellisense and auto-completion capabilities provide right insight into object types and members.
Instructions
meaningful and consistent variable naming
type prefixes and suffixes
Code Examples
leverage IDE and code introspection provide type information
let firstName: string;
let users: User[];
let config: Config;type prefix
let strFirstName: string;
let arrUsers: User[];
let objConfig: Config;type suffix
let firstNameStr: string;
let usersArr: User[];
let configObj: Config;I am a software engineer and Google Developer Expert in Web Technologies and Angular with a passion for learning, writing, speaking, teaching and mentoring. I regularly speaks at conferences and meetups around the country, and co-authored "Why Angular for the Enterprise" for O'Reilly. When not coding, I enjoy skiing, hiking, and being in the outdoors. I started lookout.dev to break down the barriers of learning in public. Learning in public fosters growth - for ourselves and others.
Have a question or comment?