Alexander B. That's no different than people pulling the same kinds of scoping stunts now. I would just like to have more granular scoping options available.
Alexander B. I really miss inline variables. I think it makes the code a lot harder to follow and especially modify (jump up jump down, jump up jump down...).
With inline variables it's also much harder to make mistakes by accidentally reusing a variable.
Anthony Frazier Good point, in my mind inline variable declaration requires scoped variables. I know Python violates this, and I dislike that about Python.
Alexander B. I find that lack of faith disturbing... Try those loops in DWScript or Smart ;-) Local variables are scoped and their names are constrained, prevents that readability issue and others to which Delphi is vulnerable.
Graeme Geldenhuys code is written once, maintained many times. The problem isn't typing, but keeping things readable and as locally scoped as possible. Having the IDE generate more code for you just makes it longer and harder to maintain and refactor.
A property is different from a variable in that you can't acquire a pointer to it, so it future proofs your class in a way a public variable won't. As for inline var declarations
Eric Grange Well C doesn't have inline variable declarations so ;)
Graeme Geldenhuys Having spent a number of years coding C++, and then returning to Delphi, I find a lot of Pascal/Delphi constructs to be detrimental to reading and understanding code, as well as writing correct code.
Scoped, inline variable declaration is one of those features. Bringing the declaration closer to where it is used makes it easier to see the type of the variable when you're reading a piece of code, especially outside of the IDE, say in a diff util. Since they're scoped, you prevent some common ways of accidentally re-using a variable, reducing the chance of bugs.
As for you complaint about typing less... in many cases typing less can actually lead to more readable code. It can allow the important implementation details to stand out, not being drowned in a wall of text.
While I don't agree with all the syntax choices in DWScript, I think there are some good ideas there and shouldn't be dismissed just like that.
Graeme Geldenhuys Even with <= 30 lines I think code is much easier to read with inline variable declarations, sometimes considerably so. In addition the tighter scoping makes it easier to be less wasteful of resources. Have you used say C++ for anything non-trivial? Java doesn't count, it's an abomination of a language :-P
Asbjørn Heid If you have to jump up and down multiple times when you need a new variable you should lean back, watch your method/routine you are in and ponder if it should be refactored because it's too long and doing way to much. Often long routines with many local variables are a sign of poor coding (spaghetti anyone?).
Stefan Glienke And if I refactor my functions into a dozen different sub-functions, then I need to jump up and down to see what's going on in them. I find that can be even more disrupting than having a single slightly long but completely linear function, due to inline scoped variables.
Asbjørn Heid Which again only happens if you fail to come up with proper names to your sub routines. But I stop arguing here because people always come up with examples why this and that principle of clean code does not apply to their code. Be it low level optimizations or just their personal preferences ("that's how I've been doing it for ages and it works!")
I have worked with Delphi for 18 years, and before that, with TP since TP 1.0 on CP/M. The core of the language is transparent to my thought processes. (That does not include generics, which owe too much to C++ in their syntax, IMHO.)
I also worked with C, which can be a tolerable language, if you write it in the spirit of Pascal. ;) Same goes for C++. The biggest failing of C++ is that they had not the courage to break C legacy code, but instead subsumed the plentiful syntactical errors in the design of C.
From the appearance of a great deal of C, one might think they were still using ASR-33s--where each character typed was almost painful--as entry devices.
As problematic as terse coding is from a maintenance perspective, the stunning verbosity of a language like C# is just as bad. It's nice to have wide monitors, but when you actually need a wide screen to scan a single line of code, then that code is a liability.
I do agree that the IDE is Delphi's most serious liability. I have turned off a number of "features" which do not work properly, as their quirks are simply too distracting, and in some cases, actually a detriment to coding and debugging.
But then, that takes us back (yet again) to the issue of long unresolved defects.
that is true
ReplyDeleteseems usefull however: NO variable inlining. That's something i like about delphi. The fixed position of local variables in a subroutine.
ReplyDeleteGreat article! Excellent points.
ReplyDeleteI'd like inline variable declaration if it let us reduce their scope (and lifetime, especially for managed types).
ReplyDeleteAnthony Frazier year and then people start with this
ReplyDeletefor var x = 0 to 5 do
for var x= 0 to 5 do
.....
While it seems that the above example does not make sense, i have seen to much c/c++ code with similar ambigous variables.
Sigh. It's not the language. It's the IDE. The repeated crashes were the reason my team revolted and wanted to move to VS.
ReplyDeleteAlexander B. That's no different than people pulling the same kinds of scoping stunts now. I would just like to have more granular scoping options available.
ReplyDeleteAlexander B. I really miss inline variables. I think it makes the code a lot harder to follow and especially modify (jump up jump down, jump up jump down...).
ReplyDeleteWith inline variables it's also much harder to make mistakes by accidentally reusing a variable.
Anthony Frazier Good point, in my mind inline variable declaration requires scoped variables. I know Python violates this, and I dislike that about Python.
Alexander B. I find that lack of faith disturbing... Try those loops in DWScript or Smart ;-)
ReplyDeleteLocal variables are scoped and their names are constrained, prevents that readability issue and others to which Delphi is vulnerable.
Graeme Geldenhuys code is written once, maintained many times. The problem isn't typing, but keeping things readable and as locally scoped as possible. Having the IDE generate more code for you just makes it longer and harder to maintain and refactor.
ReplyDeleteA property is different from a variable in that you can't acquire a pointer to it, so it future proofs your class in a way a public variable won't. As for inline var declarations
ReplyDeleteThey are scoped and constrained, so the c issues don't apply, and neither do other naming ambiguity that FPC and Delphi have.
ReplyDeleteEric Grange Well C doesn't have inline variable declarations so ;)
ReplyDeleteGraeme Geldenhuys Having spent a number of years coding C++, and then returning to Delphi, I find a lot of Pascal/Delphi constructs to be detrimental to reading and understanding code, as well as writing correct code.
Scoped, inline variable declaration is one of those features. Bringing the declaration closer to where it is used makes it easier to see the type of the variable when you're reading a piece of code, especially outside of the IDE, say in a diff util. Since they're scoped, you prevent some common ways of accidentally re-using a variable, reducing the chance of bugs.
As for you complaint about typing less... in many cases typing less can actually lead to more readable code. It can allow the important implementation details to stand out, not being drowned in a wall of text.
While I don't agree with all the syntax choices in DWScript, I think there are some good ideas there and shouldn't be dismissed just like that.
Graeme Geldenhuys Even with <= 30 lines I think code is much easier to read with inline variable declarations, sometimes considerably so. In addition the tighter scoping makes it easier to be less wasteful of resources. Have you used say C++ for anything non-trivial? Java doesn't count, it's an abomination of a language :-P
ReplyDeleteAsbjørn Heid If you have to jump up and down multiple times when you need a new variable you should lean back, watch your method/routine you are in and ponder if it should be refactored because it's too long and doing way to much. Often long routines with many local variables are a sign of poor coding (spaghetti anyone?).
ReplyDeleteStefan Glienke I don't have to jump up and down to think that inline is easier to read and prevent bugs.
ReplyDeleteStefan Glienke And if I refactor my functions into a dozen different sub-functions, then I need to jump up and down to see what's going on in them. I find that can be even more disrupting than having a single slightly long but completely linear function, due to inline scoped variables.
ReplyDeleteAsbjørn Heid Which again only happens if you fail to come up with proper names to your sub routines. But I stop arguing here because people always come up with examples why this and that principle of clean code does not apply to their code. Be it low level optimizations or just their personal preferences ("that's how I've been doing it for ages and it works!")
ReplyDeleteStefan Glienke Fair enough, might be down to domains as well. Some code lends itself more easily to be broken into chunks.
ReplyDeleteAnyway my key point was that I think inline variable declaration can improve even short routines.
I have worked with Delphi for 18 years, and before that, with TP since TP 1.0 on CP/M. The core of the language is transparent to my thought processes. (That does not include generics, which owe too much to C++ in their syntax, IMHO.)
ReplyDeleteI also worked with C, which can be a tolerable language, if you write it in the spirit of Pascal. ;) Same goes for C++. The biggest failing of C++ is that they had not the courage to break C legacy code, but instead subsumed the plentiful syntactical errors in the design of C.
From the appearance of a great deal of C, one might think they were still using ASR-33s--where each character typed was almost painful--as entry devices.
As problematic as terse coding is from a maintenance perspective, the stunning verbosity of a language like C# is just as bad. It's nice to have wide monitors, but when you actually need a wide screen to scan a single line of code, then that code is a liability.
I do agree that the IDE is Delphi's most serious liability. I have turned off a number of "features" which do not work properly, as their quirks are simply too distracting, and in some cases, actually a detriment to coding and debugging.
But then, that takes us back (yet again) to the issue of long unresolved defects.