Why the
password.trim()? Silently removing parts of the password can lead to dangerous bugs and tells me the developer didn’t peoperly consider how to sanitize input.I remember once my password for a particular organization had a space at the end. I could log in to all LDAP-connected applications, except for one that would insist my password was wrong. A
trim()or similar was likely the culprit.Another favorite of mine is truncating the password to a certain length w/o informing the user.
Saving the password truncates but validation doesn’t. So it just fails every time you try to log in with no explanation. The number of times I have seen this in a production website is too damn high.
It also can truncate on the BE side when using the damn varchar
Passwords should be hashed, not stored plain text! Hashes are always the same length so this is an immediate sign they are doing horribly insecure things with your password.
The password needs to be 8 letters long and may only contain the alphabet. Also we don’t tell you this requirement or tell you that setting the password went wrong. We just lock you out.
Figuring out what the code is doing is not the hard part. Documenting the reason you want it to do that (domain knowledge) is the hard part.
Agreed.
And sometimes code is not the right medium for communicating domain knowledge. For example, if you are writing code the does some geometric calculations, with lot of trigonometry, etc. Even with clear variable names, it can be hard to decipher without a generous comment or splitting it up into functions with verbose names. Sometimes you really just want a picture of what’s happening, in SVG format, embedded into the function documentation HTML.
Yeah. I advocate for self explanatory code, but I definitely don’t frown upon comments. Comments are super useful but soooo overused. I have coworkers that aren’t that great that would definitely comment on the most basic if statements. That’s why we have to push self explanatory code, because some beginners think they need to say:
//prints to the console console.log("hello world");I think by my logic, comments are kind of an advanced level concept, lol. Like you shouldn’t really start using comments often until you’re writing some pretty complex code, or using a giant codebase.
Comments are super useful but soooo overused
I think overusing comments is a non-issue. I’d rather have over-commented code that doesn’t need it, over undocumented code without comments that needs them. If this over-commenting causes some comments to be out of date, those instances should hopefully be obvious from the code itself or the other comments and easily fixed.
Code before:
async function createUser(user) { if (!validateUserInput(user)) { throw new Error('u105'); } const rules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/]; if (user.password.length >= 8 && rules.every((rule) => rule.test(user.password))) { if (await userService.getUserByEmail(user.email)) { throw new Error('u212'); } } else { throw new Error('u201'); } user.password = await hashPassword(user.password); return userService.create(user); }Here’s how I would refac it for my personal readability. I would certainly introduce class types for some concern structuring and not dangling functions, but that’d be the next step and I’m also not too familiar with TypeScript differences to JavaScript.
const passwordRules = [/[a-z]{1,}/, /[A-Z]{1,}/, /[0-9]{1,}/, /\W{1,}/] function validatePassword(plainPassword) => plainPassword.length >= 8 && passwordRules.every((rule) => rule.test(plainPassword)) async function userExists(email) => await userService.getUserByEmail(user.email) async function createUser(user) { // What is validateUserInput? Why does it not validate the password? if (!validateUserInput(user)) throw new Error('u105') // Why do we check for password before email? I would expect the other way around. if (!validatePassword(user.password)) throw new Error('u201') if (!userExists(user.email)) throw new Error('u212') const hashedPassword = await hashPassword(user.password) return userService.create({ email: user.email, hashedPassword: hashedPassword }); }Noteworthy:
- Contrary to most JS code, [for independent/new code] I use the non-semicolon-ending style following JavaScript Standard Style - see their no semicolons rule with reasoning; I don’t actually know whether that’s even valid TypeScript, I just fell back into JS
- I use oneliners for simple check-error-early-returns
- I commented what was confusing to me
- I do things like this to fully understand code even if in the end I revert it and whether I implement a fix or not. Committing refacs is also a big part of what I do, but it’s not always feasible.
- I made the different interface to userService.create (a different kind of user object) explicit
- I named the parameter in validatePassword plainPasswort to make the expectation clear, and in the createUser function more clearly and obviously differentiate between “the passwords”/what
passwordis. (In C# I would use a param label on callvalidatePassword(plainPassword: user.password)which would make the interface expectation and label transformation from interface to logic clear.
Structurally, it’s not that different from the post suggestion. But it doesn’t truth-able value interpretation, and it goes a bit further.
