Am 04.02.2012, 18:37 Uhr, schrieb bioinfornatics
<[email protected]>:
hi,
What should do a D lint?
- check if in code the are no mixin between space / tab for indent
- check indent (4 spaces as default)
complete the list
Do you want to collect ideas or advertise the use of 4 spaces for
indentation? Look, i would add something to your list, if I didn't have
the feeling that you have the wrong intentions with the indentions. I
recently set my tab width to 3 - it is still readable and in D I often
have deep nesting. I indent with tabs and often let that follow a stream
of spaces for alignment (on long parameter lists). I'm not sure at all if
a lint tool should care about whitespace so much, or if this is better
left to an auto-formatter. Can you make this code pass?:
fooObject.callMethod(loooooooooonnnnnnnnngPaaraaaaaameterrrrr,
1234567890 + somehting * 10,
flagA | flagB);
Ok, here is something to add to the list:
- check useless or redundant modifiers on symbols:
@safe:
const Bar foo() const {} => redundant modifier, foo() is already
'const', did you mean: const(Bar) foo() const ?
@safe int x() { return 0; } => redundant modifier, x() is already '@safe'
void very_pure() pure pure pure {} => redundant modifier, very_pure() is
already 'pure'
- It is common to use enums as constants. This is ill-advised for arrays,
because they can't just be loaded as a constant into some CPU register.
Instead a new array instance is created everywhere they are used. So
instead of enum, use immutable for arrays.
- Some poeple also think it would be good to warn about implicit
conversions between chars and integer types, or signed and unsigned
