> > > > > 1. it makes it easier to see the whole picture just looking at the loop > > > body, no need to scroll up; (The loop body might be just 10 lines of > code, > > > whereas the whole containing function sometimes has 1000s) > > > > > > 2. it isoltates the scope of such variable(s), therefore preventing > some > > > sorts of accidental misuse outside of e.g. the containing loop (which > still > > > do happen to me ocasionally in Pascal). > > > > I've already tried to make these points, nobody seems to buy it. IIRC > > Michael (vC) said that functions shouldn't be that long, so then it's > > not a problem (perhaps his world is perfect, but mine certainly isn't). > > Anyone can split a function in many others. It's not so difficult and, > actually, it should be done. > > > I'm mostly more interested in limiting the scope to prevent accidental > > use, like you. It can also offer more fine grained control of where > > managed variables get freed. > > Try to see restrictions as a good thing. > In this case, which Pascal doesn't allow to declare inline variables, > you must split big functions, which has many local variables, in > others to have a better understanding of the algorithm. At the end, > you might have a better design and reuse of the code. Everybody wins: > you, your code, Pascal team - as they don't need to change the > compiler - and Niklaus Wirth might not throw a curse in us. > > O dear, now I've dunnit...
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; Marcos says restrictions are good. The above restricts the number of lines of code while being just as (or more) readable!
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
