Hidden initiallizations ...


(Alex) #1

Look at that code:
var i:Int = 0
for i in (0..100){ ///... if (i == 50)
{
break }
}

print("i=\(i)")

What is the value of i ?? Please remove this nonsense from the language unless you are happy to see it job interview questions in future :slight_smile: My suggestion is to use the variable i in the loop instead of making hidden init of another "i" for the loop.

Everything that is hidden = evil. It is not saving time but creating bugs. Code should be clear and understandable from first view...

路路路

(Brent Royal-Gordon) #2

What is the value of i ??

0, because `for i` implicitly declares a new variable `i`. You could perhaps argue that you should have to explicitly say `for let i`, but that seems pointless because the `let` would always be necessary. (Well, unless you did a `for case` or `for _`, but those are rare constructs.)

My suggestion is to use the variable i in the loop instead of making hidden init of another "i" for the loop.

That seems like an extremely bad idea. What if the loop variable is a property or global and you accidentally end up using it implicitly? That's *way* worse than shadowing the outer variable.

路路路

--
Brent Royal-Gordon
Architechies


(Alex) #3

I strongly disagree with you. You can not "accidentally" do any thing as the name of the variable used will be written. Now it is written "i" and is not cleat what i is...
Adding "let" may help but only in case that it is not allowed to use the name "i" in the same method. Having more that one variable with the same name in one method is stupid and the language should prevent that at least.

> What is the value of i ??

0, because `for i` implicitly declares a new variable `i`. You could perhaps argue that you should have to explicitly say `for let i`, but that seems pointless because the `let` would always be necessary. (Well, unless you did a `for case` or `for _`, but those are rare constructs.)

My suggestion is to use the variable i in the loop instead of making hidden init of another "i" for the loop.

That seems like an extremely bad idea. What if the loop variable is a property or global and you accidentally end up using it implicitly? That's *way* worse than shadowing the outer variable.

路路路

On Tuesday, March 29, 2016 4:16 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

--
Brent Royal-Gordon
Architechies


(Andrey Tarantsov) #4

Having more that one variable with the same name in one method is stupid and the language should prevent that at least.

Actually, we're doing it all the time:

if let foo = foo {
聽聽...
}

var foo = foo

You can do this in a subscope, you can do this to the arguments, and you can do this to fields.

A.


(Alex) #5

And you are OK with that ???I can not imagine my team writing such code and me looking to 5 code reviews per day having to find out what the variable actually is every time :slight_smile:
For me it is OK for student projects but not for big code that have to be supported for years 鈥

路路路

On Tuesday, March 29, 2016 2:02 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:

Having more that one variable with the same name in one method is stupid and the language should prevent that at least.

Actually, we're doing it all the time:
if let foo = foo { ...}
var foo = foo
You can do this in a subscope, you can do this to the arguments, and you can do this to fields.
A.


(Andrey Tarantsov) #6

This is idiomatic Swift. I see no readability issues with that.

Of course, shadowing a local var with a for loop counter is another case. I'd say a warning is warranted there.

A.

路路路

On Mar 29, 2016, at 5:30 PM, Biala <bialata@yahoo.com> wrote:

And you are OK with that ???
I can not imagine my team writing such code and me looking to 5 code reviews per day having to find out what the variable actually is every time :slight_smile:

For me it is OK for student projects but not for big code that have to be supported for years ...

On Tuesday, March 29, 2016 2:02 PM, Andrey Tarantsov <andrey@tarantsov.com> wrote:

Having more that one variable with the same name in one method is stupid and the language should prevent that at least.

Actually, we're doing it all the time:

if let foo = foo {
聽聽...
}

var foo = foo

You can do this in a subscope, you can do this to the arguments, and you can do this to fields.

A.


(Haravikk) #7

I鈥檓 a +1 for warning in cases like that, if let foo = foo is probably fine, though personally I use different names anyway.

Actually I use a lot of Applescript style naming, though admittedly I can be a bit inconsistent about it. For example, I like using eachFoo as a name for a loop variable like so:

聽聽for eachIndex in 1 ..< 100 { 鈥 }

Which can read nicely as natural language, but since I don鈥檛 use eachFoo anywhere else, helps to avoid name collisions. If eachFoo is optional, then I might unwrap the value into theFoo instead like-so:

聽聽let theValues:[Int?] = []
聽聽for eachValue in theValues {
聽聽聽聽if let theValue = eachValue { /* Do some stuff */ }
聽聽聽聽else { /* Do some other stuff */ }
聽聽}

I actually see a surprising number of examples like:

聽聽for i in 1 ..< 100 { 鈥 }

But does anyone actually use these? Since I learned to stop using c-style loops in Swift I haven鈥檛 used single letter variables at all, so this seems like partly an issue of choosing bad variable names; not saying mine are better, but I find that they work well for me, even if they鈥檙e a bit longer overall. Unless I鈥檓 implementing some kind of formula with well understood letters for variables I wouldn鈥檛 use such short names anywhere, and even then I鈥檇 probably try to find out what each variable is and find a full name for it, for my own sake.

路路路

On 29 Mar 2016, at 12:39, Andrey Tarantsov via swift-evolution <swift-evolution@swift.org> wrote:

This is idiomatic Swift. I see no readability issues with that.

Of course, shadowing a local var with a for loop counter is another case. I'd say a warning is warranted there.

A.

On Mar 29, 2016, at 5:30 PM, Biala <bialata@yahoo.com <mailto:bialata@yahoo.com>> wrote:

And you are OK with that ???
I can not imagine my team writing such code and me looking to 5 code reviews per day having to find out what the variable actually is every time :slight_smile:

For me it is OK for student projects but not for big code that have to be supported for years ...

On Tuesday, March 29, 2016 2:02 PM, Andrey Tarantsov <andrey@tarantsov.com <mailto:andrey@tarantsov.com>> wrote:

Having more that one variable with the same name in one method is stupid and the language should prevent that at least.

Actually, we're doing it all the time:

if let foo = foo {
聽聽...
}

var foo = foo

You can do this in a subscope, you can do this to the arguments, and you can do this to fields.

A.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Andrey Tarantsov) #8

Actually I use a lot of Applescript style naming, though admittedly I can be a bit inconsistent about it. For example, I like using eachFoo as a name for a loop variable like so:

聽聽for eachIndex in 1 ..< 100 { 鈥 }

Which can read nicely as natural language, but since I don鈥檛 use eachFoo anywhere else, helps to avoid name collisions. If eachFoo is optional, then I might unwrap the value into theFoo instead like-so:

聽聽let theValues:[Int?] = []
聽聽for eachValue in theValues {
聽聽聽聽if let theValue = eachValue { /* Do some stuff */ }
聽聽聽聽else { /* Do some other stuff */ }
聽聽}

Interesting! :slight_smile: I should explore this, sounds fun in some cases.

I typically just use the bare word:

for value in values {
聽聽if let value = value {
聽聽聽聽foo(value)
聽聽}
}

...but sometimes that clashes with an argument or field, and yours could be a good convention to resolve those cases.

A.