Exceptional coding style

Rob T alanb at ucora.com
Fri Jan 18 00:50:11 PST 2013


On Friday, 18 January 2013 at 08:13:48 UTC, deadalnix wrote:
> Believing that one code formatting will inherently be better 
> than what a formatted can do is very similar to the assertion 
> often heard that code generated by the compiler is worse than 
> hand written assembly or many other recurring similar topic 
> coming again and again in dev discussion.
>
> It has been shown more than once that you can beat the compiler 
> on some carefully selected piece of code, but generally 
> speaking, you have not even a small chance to beat it at a 
> program scale or when certain optimizations kicks in. Same goes 
> for the formatter.
>
> As a matter of fact, the time you spend formatting can be 
> better spent elsewhere, and the consistency you win in the 
> process has many benefits : cleaner diffs and easiers merges 
> because you have no formatting conflict. The codebase is 
> consistent, and the tool can even help you by reformatting 
> confusing stuff is clearer ones.
>
> Not to mention that all refactoring tools suffer badly if you 
> don't have a proper formatter : you spent as much time 
> reformatting the code than you would have needed to do the 
> refactoring itself.

When reading your post, I thought of replacing the concept of an 
automatic source code formatter with an automatic garbage 
collector. We've seen this kind of debate before, with the same 
sort of arguments in favor and against.

It could very well be that so long as the implementation is good, 
the idea of a standardized enforced format may be better than the 
current alternative. It's like the difference between machine 
tooling vs what you get from an anvil and hammer approach. 
Consistency vs inconsistency.

--rt


More information about the Digitalmars-d mailing list