On Mon, Apr 20, 2009 at 10:19, Mattias Gaertner
<nc-gaert...@netcologne.de> wrote:
>> >> 4c) Add 'Empty begin..end' block, probably with the same check for
>> >> the comments as in (4a)
>> >> 4d) Add 'Single statement in begin..end block'
>> >> 4e) Add 'Too many nesting statements' and 'Too many nesting
>> >> procedures'
>> >> 4f) Add 'Line loo long' with default limit of perhaps 80
>> >> or 90 characters.
>> >> 4g) Add 'Incorrect indentation' for the cases where
>> >> indentation does not correctly represent
>> >> statement nesting.
>> >
>> > Are you joking or are you a grammar nazi?
>>
>> Well, 'grammar nazi' can not exist for a compiled language, since
>> compiler will simply reject grammatically incorrect source.
>> So you probably mean 'stylistic nazi'. Well, yes, actually I am ;-)
>
> ;)
> And you want the IDE to be a stylistic nazi like yourself.
>
> Well in some way I understand you. I don't like macros and I will
> eventually add a category to list all macros.
> But IMO it is more important to provide a tool to help fixing these
> things. Which means for the examples you gave ...
>
>>[...code formatting like indentation, empty or long lines...]
>
> ... a code formatter.
Please note that stylistic-nazi examples I gave are different from the checks
I proposed to add. One difference, which I considered while making the
latter list,
is whether code formatter will be able to fix it.
Let's review:
(4c) and (4d) are in principle fixable automatically, but the tool to do that
should definitely not be called 'formatter'.
(4e) has nothing to do with formatting
(4f) seems like a no-brainer, but it has issues too:
1) there are times when slightly overlong lines are the lesser of two evils,
like e.g. DebugLn lines in Lazarus or some list-formatted array
initialization.
2) line splitting, sepecially for complex expression, seriously
affects readability,
so the choice of the optimal line break position can not be automated.
(4g) again seems simple, but 'auto-fixing' can in this can make things _worse_
by hiding the problem. Consider the code (idented by '~' characters):
for i := 0 to High(A) do
~~if A[i] > m then
Writeln(A[i]);
The actual error is a missing 'm := i' line after the if, but
formatter would change it to
for i := 0 to High(A) do
~~if A[i] > m then
~~~~Writeln(A[i]);
Obtaining correctly formatted but semantically wrong code.
Hint, on the other hand, will simply point programmer to the
problematic location
where he will hopefully notice and fix it.
--
Alexander S. Klenin
_______________________________________________
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
