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

Am 04.02.2012, 18:37 Uhr, schrieb bioinfornatics <bioinfornatics@fedoraproject.org>:

> 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