4 ms·

> 4. No literals Generally I agree with you here, but I think what the post is getting at is more the one case where you do want a variable in place of a liter

> 4. No literals Generally I agree with you here, but I think what the post is getting at is more the one case where you do want a variable in place of a literal - when passing the literal into a function where its purpose isn't immediately obvious. Passing the literal behind a more meaningful variable name can provide cleaner, self-documenting code in cases where, for example, modifying the function isn't possible and writing an adaptor would be overkill.

akkartik 11y ago
The second-most egregious pattern I see at work: const char* kEmpty = ""; Makes me want to poke my eyes out with a stick everytime I see kEmpty used.. (The most egregious thing is spaces inside parens. But that's just a personal preference. In general I tend to be quite laissez-faire about tolerating different styles, and consider style guides to be a pox because they tend to give the subliminal message that your code is done when it complies with the style guide.)
- imron 11y ago
  You mean like this: call_function( some_argument ); If so, I have to disagree strongly. Having the spaces inside the parens makes it far easier to scan the code.
- davnicwil 11y ago
  I'm 100% with you, the variable name kEmpty here is completely tautological - it just describes the literal in a different, clunkier way, and doesn't add any information. Kind of similar to something like nameOfSteve = "steve" The case where it's useful is where instead you'd call the variable referring to a constant something like dollarCurrencyCode = "USD", where you have to use an api which takes a currency code but you will always pass "USD". To the uninitiated reader, what purpose does the literal "USD" serve - what does it mean? It's not clear, because they don't know the api, and may not intuit currency codes. Putting it behind the dollarCurrencyCode variable name makes it a lot clearer on first glance. If they care to know what the dollarCurrencyCode is 'under the hood', they can then look, but this is a lower level detail of the underlying api and doesn't help with understanding.
rhinoceraptor 11y ago
I always prefer to use literals in tests, I had the case once where I was checking that foo was equal to bar. In reality, both were null, so the test passed.

akkartik 11y ago

The second-most egregious pattern I see at work: const char* kEmpty = ""; Makes me want to poke my eyes out with a stick everytime I see kEmpty used.. (The most egregious thing is spaces inside parens. But that's just a personal preference. In general I tend to be quite laissez-faire about tolerating different styles, and consider style guides to be a pox because they tend to give the subliminal message that your code is done when it complies with the style guide.)

imron 11y ago
You mean like this: call_function( some_argument ); If so, I have to disagree strongly. Having the spaces inside the parens makes it far easier to scan the code.
davnicwil 11y ago
I'm 100% with you, the variable name kEmpty here is completely tautological - it just describes the literal in a different, clunkier way, and doesn't add any information. Kind of similar to something like nameOfSteve = "steve" The case where it's useful is where instead you'd call the variable referring to a constant something like dollarCurrencyCode = "USD", where you have to use an api which takes a currency code but you will always pass "USD". To the uninitiated reader, what purpose does the literal "USD" serve - what does it mean? It's not clear, because they don't know the api, and may not intuit currency codes. Putting it behind the dollarCurrencyCode variable name makes it a lot clearer on first glance. If they care to know what the dollarCurrencyCode is 'under the hood', they can then look, but this is a lower level detail of the underlying api and doesn't help with understanding.

rhinoceraptor 11y ago

I always prefer to use literals in tests, I had the case once where I was checking that foo was equal to bar. In reality, both were null, so the test passed.