[nem-en] loving Nemerle
Kamil Skalski
kamil.skalski at gmail.com
Thu Oct 27 19:57:40 CEST 2005
>
> This would be great. Actually IMO such a thing should be enabled by
> default. The more the compiler cares about, the better. If some of the
> work can be taken care of by the machine, let's shift the burden to it!
And why do you want to force people to conform to the "one coding-style way"?
I think that in general compiler should warn only about things, which
could potentially be an error, like variable which is never assigned
to.
On the other hand it is not always the best approach.
There is a number of warnings, which I like in ncc:
- check if instance method actually uses 'this' pointer, otherwise it
can be made static
- check if hard cast (:>) is necessary or you could just do type enforcement:
foreach (x :> string in ["1", "2", "3"]) { // cast is not needed
...
}
- method is unused
etc.
> code and time savings. Why not employ this strategy in the case of coding
> conventions, which are actually *very* important (at least to the human
> part of the software creation process).
Of course, it would be nice to have such a style checker, somethink
like FxCop, though just like someone pointed out on Mono list,
probably it is better to do such things on IL level, so every language
get benefit from it. In places, where we can nicely plug into compiler
it would also be a nice thing to have.
Something like checking if public members are CamelCased, etc. should
be easy to do.
> use a "predefined" style (such as ncc-style for example) or perhaps
> it could be detected "on the fly" and consistency checked in the rest
> of the source code.
I would prefer to see it as a separate tool / compilation pass, but
probably just for performance reasons and avoiding the expolsion of
complexity in compiler.
> I totally believe the programmer should be restricted to doing only what
> they are supposed to. And the more can be forced on compiler level, the
> better.
Sounds like a prison to me ;P
--
Kamil Skalski
http://nazgul.omega.pl
More information about the devel-en
mailing list