iOS Coding style: Where do you defined your local method variables?

[NickFalk]

So where do you place your local method variables?
A question of style, as I'm currently lacking in this department. (One of the many bonuses coming from being mostly self-taught).

At the moment I seem to just place the definition of local method-variables anywhere in the vicinity of where I'll first use them. The idea of course being that the declaration and use of said variables should be as close to each other as possible. Often this leads to the code being easier to decipher, but the code isn't nearly as neat/clean looking as I would like. I am therefore starting to reconsider this approach.

I am considering placing the definitions as early as possible in the method which should give a nice and quick overview of any local variables that are going to be used. This should tidy the code up as well.

Any comments/alternatives/thoughts?

 

[jiminaus]

I can only give you my personal experience.

I started with the style of putting variables at the top of a method. I did this thinking that if someone was reading my code and they see a variable, they would only need to look at the top of the function to find out it's type. I also kept my variables in alphabetical order. I would even go as far as deferring initialisation until after all the local variable declarations so as to be able to maintain the alphabetical ordering. ... No wonder I ended up as a Librarian.

But I don't do that anymore. When I started refactoring, I found it much easier to be able to move my code around if the variable declaration was close to its first use. Also having then been coding long enough to have to go back a read my (typically undocumented) old code, I found it would have actually have been easier if the variable was declared close to it's use. I found myself jumping back and forth to the top of the method.

Now...

Well now this is not much of an issue, either way. Now I keep my methods as short and sweet as possible. No method is more than 20 lines, so it's easy to see and understand the whole method at once. If a method grows to big, I stop and reassess what the methods trying to do. If it's trying to do too much, I refactor it in smaller methods.

And now I tend to use a style of variable usage that I learnt from functional programming. I avoid ever reassigning a variable, I treat my variables as read only. I find this help debugging enormously. And even basic data-flow analysis will reuse registers and stack locations, so with optimisations it's doesn't use more memory.

 

[NickFalk]

I definitely agree that shorter methods are the way to go, preferably ones that only does ONE thing. (Every time I get into trouble it seems it's because I've strayed from this). It is a difficult balance at times though. At the moment I'm working on some path-finding stuff and finding a sensible balance between readability and compactness of code is quite challenging.