On 20/02/2019 14:36, Paul van Helden wrote:
So the argument against is: (1) split your long functions, because you
should; and (2) Wirth didn't do it, so good it is not.
Long functions *might* be an indication of bad design, but you know,
sometimes I have a long function that doesn't make sense to split.
Here is a good article about inline vars:
http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html
What's not to like about for var I:=0 to Count-1 do.. ?
Or var MyDict:=TDictionary<Integer,String>.Create;
1) "for" (and other) loops with a long body also exist.
So the problem is still there, if I encounter "i" in the middle of a
1000 line for-loop, I still do not see its declaration. So far, no loss,
but no gain either.
2) Nested loops exist. If in the middle of such a 1000 line for-loop, I
want to declare another loop, then I need to find a free identifier for
that variable.
Today, I can do that by looking at the declaration on top of the
procedure (and afaik depending on context, the class fields).
With inline declaration, I have to find each of the 10 surrounding
for-loops, scattered over a 1000 lines (And that is ignoring any
variables declared inline, but not as part of a for-loop). I would say
that is definitely worse.
But just my 2 cents.
Now do not tell me that those loops should be refactored, because they
are based on your statement that this is not always sensible.
3) As for duck typing:
for var i:= Func1 to Func2 do;
What if that is "QWord to int64(or at some future points changes to that)?
What will "i" then be? And why?
Or should that be a compile error? (Probably the best)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
