Small is good. Small is simple.
We should strive to keep things small in our development work. Keep routines short and simple. Use as few local variables as possible. Avoid long parameter lists. Keep scope as narrow as possible.
If you find yourself challenged by these things, it suggests the need for practice and thought. Routines which contain hundreds of lines, or even a single hundred lines, are difficult to write, to test, and to maintain.
Likewise, local variables become unmanageable when you use dozens of them in a large routine.
Long parameter lists are as troublesome as the use of too many variables.
Your short routines will be easy to write and easy to debug. More important, they will be easy for other developers to understand.
If your application has a future, then it must be logically designed and clearly written. Unless you want to be the only developer who can maintain it, you need to make your code tell other developers what it does, and why it does it.
Simply. Clearly. Briefly.
I disagree with ” Use as few local variables as possible.” if that means reusing local variables for different purposes. Having a for variable and another index variable in my book is preferable over reusing that for variable (somewhere else outside the loop). E.g.
var
i: integer;
Idx: integer;
begin
for i := 0 to 10 do begin
// some code using i
end;
// some more code here
if List.FindValue(‘bla’, Idx) then
doSomething(List[Idx]);
end;
Here, it would be possible to use i instead of Idx and “save” one local variable, but I think it makes it less clear what is being done.
Thomas, I agree with your point. I was too focused on my own brevity.
But with small methods, I would argue there is no conflict in using “as few as possible.” I did mention the idea that our code needs to communicate to the developers who follow us, and using “idx” is a good example of that. I stopped using “i” as an index years ago, and it is not that “idx” is so much better, but that it lends itself to usage such as: “colIdx, rowIdx: Integer”, and those indices are much better than “i, j: Integer”, even in a small routine.