Do you mean by this that TODO comments SHOULD be avoided in Scala?
Without further context, I'm assuming that this was the idea. Such rule/recommendation sounds reasonable as leaving notes/TODOs to future self & colleagues is a an excuse to acknowledge that "the work is not done here" (for various definitions of done) or "I'll get back to this some day" (that day usually never comes). In the end, every TODO comment is another kind of technical debt put under the rug. I prefer creating a task in the issue tracker instead thus making it more obvious to the developer team and thus putting it explicitly in a technical backlog that's at least more visible.
However, this sounds to me like a language-agnostic recommendation of which there are plenty that could be included which could overload Scala best practices. For example, some recommendations could be applied to higher level aspects like Scala software design - e.g. a language-agnostic Robustness principle a.k.a. Postel's Law or some more Scala-specific design principles like those in Li Haoyi's.
It seems like either these best practices should have a well-defined scope or to specifically focus on Scala best practices as the repo name implies. If the latter is the case this issue could be closed. :blush:
Do you mean by this that TODO comments SHOULD be avoided in Scala?
Without further context, I'm assuming that this was the idea. Such rule/recommendation sounds reasonable as leaving notes/TODOs to future self & colleagues is a an excuse to acknowledge that "the work is not done here" (for various definitions of done) or "I'll get back to this some day" (that day usually never comes). In the end, every TODO comment is another kind of technical debt put under the rug. I prefer creating a task in the issue tracker instead thus making it more obvious to the developer team and thus putting it explicitly in a technical backlog that's at least more visible.
However, this sounds to me like a language-agnostic recommendation of which there are plenty that could be included which could overload Scala best practices. For example, some recommendations could be applied to higher level aspects like Scala software design - e.g. a language-agnostic Robustness principle a.k.a. Postel's Law or some more Scala-specific design principles like those in Li Haoyi's.
It seems like either these best practices should have a well-defined scope or to specifically focus on Scala best practices as the repo name implies. If the latter is the case this issue could be closed. :blush: