4 ms·

There’s two problems, naming is hard and people think it doesn’t matter, that it’s just semantics or bike shedding when actually it’s probably one of the most i

There’s two problems, naming is hard and people think it doesn’t matter, that it’s just semantics or bike shedding when actually it’s probably one of the most important things. Naming things correctly is as important as well written code itself, it’s all about communication. I really liked the demonstration of how you can make exception names more explicit.

dgb23 5y ago
> just semantics To expand on this, I think we can drop the "just". Conveying semantics is one of the core benefits of using a high level language. Modern languages have recognized this and promote conventions that are more in line of what the author is suggesting. Go and Rust tell a story about re-usable interfaces/traits. Naming is even more important here, since an overly specific name for an interface would make it confusing to use it in different context (which has stronger support since you can supply interfaces/traits on the consumer side of a type). The exception examples are indeed very good and well reasoned. The context is implied and even enforced by language constructs here. On the other hand there are cases where explicit verbosity is useful, not necessarily in regards to naming: I sometimes like branching logic to be explicit, so you don't need to understand all of the execution context (by reading/testing the code) to understand an isolated branch. Another case can be data modelling. Temporal records can provide a transaction_from and a transaction_to field so the record explicitly states its temporal validity in isolation. Being explicit here is more verbose but has benefits for reasoning. I assume this is the intent of the (overly) explicit naming convention in Java et al. But it goes too far too often.
einpoklum 5y ago
> just semantics One plus two equals two, if by "plus" we mean "times". It's just semantics! ... the semantics of the word "plus".

dgb23 5y ago

> just semantics To expand on this, I think we can drop the "just". Conveying semantics is one of the core benefits of using a high level language. Modern languages have recognized this and promote conventions that are more in line of what the author is suggesting. Go and Rust tell a story about re-usable interfaces/traits. Naming is even more important here, since an overly specific name for an interface would make it confusing to use it in different context (which has stronger support since you can supply interfaces/traits on the consumer side of a type). The exception examples are indeed very good and well reasoned. The context is implied and even enforced by language constructs here. On the other hand there are cases where explicit verbosity is useful, not necessarily in regards to naming: I sometimes like branching logic to be explicit, so you don't need to understand all of the execution context (by reading/testing the code) to understand an isolated branch. Another case can be data modelling. Temporal records can provide a transaction_from and a transaction_to field so the record explicitly states its temporal validity in isolation. Being explicit here is more verbose but has benefits for reasoning. I assume this is the intent of the (overly) explicit naming convention in Java et al. But it goes too far too often.

einpoklum 5y ago

> just semantics One plus two equals two, if by "plus" we mean "times". It's just semantics! ... the semantics of the word "plus".