Return to Answer

I think the student's problem is not with types, but first with the parsing of complex expressions (not to be confused with the tracing of it's evaluation). Mentally building the abstract syntax tree from the linear text representation.

First rewrite remove the extra parentheses at right, and introduce a line break

if (    (n+"").length() 
     == ((n+1)+"").length()) {

to split the expression. It make clear you are comparing two lengths = ints.

Second make it obvious that the 2 sides of the comparison have the same pattern

if (    (n    +"").length() 
     == ((n+1)+"").length()) {

a cosmetic change which drastically reduces the problem space : there's a hope that if we can figure what happens at the left for n, we'll understand the right part too.

What's left is producing a string from an int. Not the best way (what about Integer.toString ?) but anyway.

Actually, only one typecast is involved, twice.

As for "writing code he can't understand later", it'a common symptom. the probleme is not he cannot understand it, but that he wrote too complex code in the first place. Beginners always overestimate their cognition abilities. And they are reluctant to decomposition because it requires an effort to clearly identify a sub-task (and find a nice name for it !)

Remedies : insist on

• using auxiliary variables
• define and use of "helper" functions, predicates.

I think the student's problem is not with types, but first with the parsing of complex expressions (not to be confused with the tracing of it's evaluation). Mentally building the abstract syntax tree from the linear text representation.

First rewrite remove the extra parentheses at right, and introduce a line break

if (    (n+"").length() 
     == ((n+1)+"").length()) {

to split the expression. It make clear you are comparing two lengths = ints.

Second make it obvious that the 2 sides of the comparison have the same pattern

if (    (n    +"").length() 
     == ((n+1)+"").length()) {

a cosmetic change which drastically reduces the problem space : there's a hope that if we can figure what happens at the left for n, we'll understand the right part too.

What's left is producing a string from an int. Not the best way (what about Integer.toString ?) but anyway.

Actually, only one typecast is involved, twice.

As for "writing code he can't understand later", it'a common symptom. The problem is not he cannot understand it, but that he wrote too complex code in the first place. Beginners always overestimate their cognition abilities. And they are reluctant to decomposition because it requires an effort to clearly identify a sub-task (and find a nice name for it !)

Remedies : insist on

• using auxiliary variables
• define and use of "helper" functions, predicates.

I think the student's problem is not with types, but first with the parsing of complex expressions (not to be confused with the tracing of it's evaluation)

First rewrite remove the extra parentheses at right, and introduce a line break

if (    (n+"").length() 
     == ((n+1)+"").length()) {

to split the expression. It make clear you are comparing two lengths = ints.

Second make it obvious that the 2 sides of the comparison have the same pattern

if (    (n    +"").length() 
     == ((n+1)+"").length()) {

which drastically reduces the problem space : there's a hope that if we can figure what happens at the left for n, we'll understand the right part too.

What's left is producing a string from an int. Not the best way (what about Integer.toString ?) but anyway.

Actually, only one typecast is involved, twice.

As for "writing code he can't understand later", it'a common symptom. the probleme is not he cannot understand it, but that he wrote too complex code in the first place. Beginners always overestimate their cognition abilities. And they are reluctant to decomposition because it requires an effort to clearly identify a sub-task (and find a nice name for it !)

Remedies : insist on

• using auxiliary variables
• define and use of "helper" functions, predicates.

I think the student's problem is not with types, but first with the parsing of complex expressions (not to be confused with the tracing of it's evaluation). Mentally building the abstract syntax tree from the linear text representation.

First rewrite remove the extra parentheses at right, and introduce a line break

if (    (n+"").length() 
     == ((n+1)+"").length()) {

to split the expression. It make clear you are comparing two lengths = ints.

Second make it obvious that the 2 sides of the comparison have the same pattern

if (    (n    +"").length() 
     == ((n+1)+"").length()) {

a cosmetic change which drastically reduces the problem space : there's a hope that if we can figure what happens at the left for n, we'll understand the right part too.

What's left is producing a string from an int. Not the best way (what about Integer.toString ?) but anyway.

Actually, only one typecast is involved, twice.

As for "writing code he can't understand later", it'a common symptom. the probleme is not he cannot understand it, but that he wrote too complex code in the first place. Beginners always overestimate their cognition abilities. And they are reluctant to decomposition because it requires an effort to clearly identify a sub-task (and find a nice name for it !)

Remedies : insist on

• using auxiliary variables
• define and use of "helper" functions, predicates.

I think the student's problem is not with types, but first with the parsing of complex expressions.

First rewrite remove the extra parentheses at right, and introduce a line break

if (    (n+"").length() 
     == ((n+1)+"").length()) {

to split the expression. It make clear you are comparing two lengths = ints.

Second make it obvious that the 2 sides of the comparison have the same pattern

if (    (n    +"").length() 
     == ((n+1)+"").length()) {

which drastically reduces the problem space : there's a hope that if we can figure what happens at the left for n, we'll understand the right part too.

What's left is producing a string from an int. Not the best way (what about Integer.toString ?) but anyway.

Actually, only one typecast is involved, twice.

As for "writing code he can't understand later", it'a common symptom. the probleme is not he cannot understand it, but that he wrote too complex code in the first place. Beginners always overestimate their cognition abilities. And they are reluctant to decomposition because it requires an effort to clearly identify a sub-task (and find a nice name for it !)

Remedies : insist on

• using auxiliary variables
• define and use of "helper" functions, predicates.

I think the student's problem is not with types, but first with the parsing of complex expressions (not to be confused with the tracing of it's evaluation)

First rewrite remove the extra parentheses at right, and introduce a line break

if (    (n+"").length() 
     == ((n+1)+"").length()) {

to split the expression. It make clear you are comparing two lengths = ints.

Second make it obvious that the 2 sides of the comparison have the same pattern

if (    (n    +"").length() 
     == ((n+1)+"").length()) {

which drastically reduces the problem space : there's a hope that if we can figure what happens at the left for n, we'll understand the right part too.

What's left is producing a string from an int. Not the best way (what about Integer.toString ?) but anyway.

Actually, only one typecast is involved, twice.

As for "writing code he can't understand later", it'a common symptom. the probleme is not he cannot understand it, but that he wrote too complex code in the first place. Beginners always overestimate their cognition abilities. And they are reluctant to decomposition because it requires an effort to clearly identify a sub-task (and find a nice name for it !)

Remedies : insist on

• using auxiliary variables
• define and use of "helper" functions, predicates.