6 ms·

Study the idioms of whatever language you are using. If you're writing production code, consistency is everything. Don't write anything surprising or clever - y

Study the idioms of whatever language you are using. If you're writing production code, consistency is everything. Don't write anything surprising or clever - you'll just paint yourself into a corner later, and it'll be impossible to maintain. Boring code is good code. Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously

sgift 9y ago
Please, everyone who thinks, "I just expect correct inputs" take note of part two. I've had so many discussions with colleagues about that "Why don't you check for null pointers and give an error message?" "I think it's perfectly fine to just crash with a null pointer, I don't expect null pointers." That attitude hurts everyone who has to support what you write. edit: Reformatted as a habit "Make sure whatever you write can be supported without unnecessary headaches."
- nostrademons 9y ago
  Only if a.) you can do something to recover from the null pointer or b.) you can provide more information about its cause than you could recover from an ordinary stack trace. Otherwise you're just adding code without changing the ultimate result of the NPE: a debugging session. Assertions, however, are great. If you can force the program to throw that NPE closer to the point where it actually illegitimately became null, the debugging session becomes much shorter. Null-safety in the type system (like with most modern languages: Swift, Haskell, Kotlin, Scala, Rust, etc.) is even better.
  - sgift 9y ago
    I have almost never seen a program where you have neither a nor b, but I agree - if you are in a situation where neither a nor b apply, don't do anything. And: Using a different language is always a great idea, but often not possible.
  - brlewis 9y ago
    This! I especially see this problem in Java, where IDEs always suggest catching an exception. Like a dog chasing cars, you really should think through what you're going to do when you catch one. I've wasted a lot of time debugging problems that get masked over by try/catch only to pop up at some later point in a seemingly unrelated part of the code.
- pards 9y ago
  This is what Martin Fowler refers to as the Tolerant Reader pattern. https://martinfowler.com/bliki/TolerantReader.html https://martinfowler.com/bliki/TolerantReader.html Code should tolerate all sorts of bad inputs. Code should produce pristine outputs. Just like being a model member of society
  - vram22 9y ago
    I think I read somewhere that Jonathan Postel (Internet pioneer) also had a rule advising that. Googled and found it: https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Jon_Postel https://en.wikipedia.org/wiki/Jon_Postel "In his lifetime he was known as the "god[2] of the Internet" for his comprehensive influence on the medium."
minademian 9y ago
"Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously" Wisdom.
ryandrake 9y ago
Think about your error handling best practices. Mine are: 1. Re-structure your logic so the error cannot happen 2. If you can't do 1, recover from the error silently and continue on with the program 3. If you can't do 2, handle the error gracefully and notify the user of what state is changed, letting them choose whether or not to continue 4. If you can't do 3, inform the user of what happened and ideally provide the user corrective action they can take, then exit cleanly with an error code 5. If you can't do 4, exit cleanly with as descriptive of an error code as you can 6. If you can't do 5, you're probably faced with crashing or exiting with some unhandled exception. This is a bug that should never go into production. Always be looking for opportunities to move your code up that hierarchy. Moving every 6 to 5 is my personal bar for barely acceptable quality. 4->3 is usually a big win (basically anything that prevents the program from exiting).
- ahoka 9y ago
  "2. If you can't do 1, recover from the error silently and continue on with the program" I think that defensive programming is the worst way of dealing with errors. You are now silently diverging from your business requirements by making up data.
  - ryandrake 9y ago
    Thanks for the reply. Yep, this is a topic that reasonable people can disagree about. I suppose I could add "if there's no loss of user data, recover from the error silently and continue on with the program". An example of #2 would be a network connection failure that can be retried without consequence to business logic.
freyawest18 9y ago
Whenever I need to know any idiom, I like to go to http://idioms.in/ http://idioms.in/ website at the drop of a hat.

sgift 9y ago

Please, everyone who thinks, "I just expect correct inputs" take note of part two. I've had so many discussions with colleagues about that "Why don't you check for null pointers and give an error message?" "I think it's perfectly fine to just crash with a null pointer, I don't expect null pointers." That attitude hurts everyone who has to support what you write. edit: Reformatted as a habit "Make sure whatever you write can be supported without unnecessary headaches."

nostrademons 9y ago
Only if a.) you can do something to recover from the null pointer or b.) you can provide more information about its cause than you could recover from an ordinary stack trace. Otherwise you're just adding code without changing the ultimate result of the NPE: a debugging session. Assertions, however, are great. If you can force the program to throw that NPE closer to the point where it actually illegitimately became null, the debugging session becomes much shorter. Null-safety in the type system (like with most modern languages: Swift, Haskell, Kotlin, Scala, Rust, etc.) is even better.
- sgift 9y ago
  I have almost never seen a program where you have neither a nor b, but I agree - if you are in a situation where neither a nor b apply, don't do anything. And: Using a different language is always a great idea, but often not possible.
- brlewis 9y ago
  This! I especially see this problem in Java, where IDEs always suggest catching an exception. Like a dog chasing cars, you really should think through what you're going to do when you catch one. I've wasted a lot of time debugging problems that get masked over by try/catch only to pop up at some later point in a seemingly unrelated part of the code.
pards 9y ago
This is what Martin Fowler refers to as the Tolerant Reader pattern. https://martinfowler.com/bliki/TolerantReader.html https://martinfowler.com/bliki/TolerantReader.html Code should tolerate all sorts of bad inputs. Code should produce pristine outputs. Just like being a model member of society
- vram22 9y ago
  I think I read somewhere that Jonathan Postel (Internet pioneer) also had a rule advising that. Googled and found it: https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Jon_Postel https://en.wikipedia.org/wiki/Jon_Postel "In his lifetime he was known as the "god[2] of the Internet" for his comprehensive influence on the medium."

minademian 9y ago

"Take error handling really seriously. A program that can gracefully reject input with a detailed error message is far better than one that crashes mysteriously" Wisdom.

ryandrake 9y ago

Think about your error handling best practices. Mine are: 1. Re-structure your logic so the error cannot happen 2. If you can't do 1, recover from the error silently and continue on with the program 3. If you can't do 2, handle the error gracefully and notify the user of what state is changed, letting them choose whether or not to continue 4. If you can't do 3, inform the user of what happened and ideally provide the user corrective action they can take, then exit cleanly with an error code 5. If you can't do 4, exit cleanly with as descriptive of an error code as you can 6. If you can't do 5, you're probably faced with crashing or exiting with some unhandled exception. This is a bug that should never go into production. Always be looking for opportunities to move your code up that hierarchy. Moving every 6 to 5 is my personal bar for barely acceptable quality. 4->3 is usually a big win (basically anything that prevents the program from exiting).

ahoka 9y ago
"2. If you can't do 1, recover from the error silently and continue on with the program" I think that defensive programming is the worst way of dealing with errors. You are now silently diverging from your business requirements by making up data.
- ryandrake 9y ago
  Thanks for the reply. Yep, this is a topic that reasonable people can disagree about. I suppose I could add "if there's no loss of user data, recover from the error silently and continue on with the program". An example of #2 would be a network connection failure that can be retried without consequence to business logic.

freyawest18 9y ago

Whenever I need to know any idiom, I like to go to http://idioms.in/ http://idioms.in/ website at the drop of a hat.