Re:Exceptional Naming
by dgb23 on Saturday June 26, 2021 @09:02AM
(#27641485)
> 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.
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.