5 ms·

Some of these could serve as philosophical starting points but are a bit too dogmatic for "rules". 1. DRY I like the Rule of Three better, and even that is fl

Some of these could serve as philosophical starting points but are a bit too dogmatic for "rules". 1. DRY I like the Rule of Three better, and even that is flexible. It's important to find an underlying abstraction and not just extract common chunks of code because they happen to be similar. 4. No literals Eh, not really. Most of the time I'd rather just see the value and not have to follow a reference to the definition of a constant. 5. Avoid dependencies Yeah, probably true for application level settings like he describes, but don't go crazy with it. The goal is to have clean readable code and tests. Its just a headache when everything is a FooImpl of a FooInterface, for instance, and not really a win for testability.

davnicwil 11y ago
> 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.
xyzzy4 11y ago
Some people take DRY too far and use it as an excuse to create way too many levels of abstraction so that code is never copy + pasted.

davnicwil 11y ago

> 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.

xyzzy4 11y ago

Some people take DRY too far and use it as an excuse to create way too many levels of abstraction so that code is never copy + pasted.