I think that Kotlin does help, if you don't take it to an extreme. It handles the null value issue much better than Java does, and some of the constructs allow you to focus more on the code. Another of the constructs, automatically determining the type of a variable, is also extremely helpful in facilitating not losing context.
However, some of the constructs do take you out of the context of the code so one needs to be careful.
At the risk of being controversial, there is another coding practice that I think takes people out of context when reading code, the practice of putting the starting brace { at the end of one line (with an if or while) and the end brace at the start of another line. I think that having the braces line up makes it a lot easier to follow the start and end of a block. What would make it better is if the IDEs showed braces more intelligently, i.e. as one continuous vertical brace spanning the whole block, without necessitating the need for unneeded vertical spaces. (See attached image.)
PFJ uses the same idea as Kotlin (type separation) but does not require "double" type system.
Type inference (especially how it is implemented in Kotlin) can hide part of context.
Finally, code formatting does not matter much as long as it's consistent. If bracket placing causes problems, most likely you have too deeply nested code.
With respect to your type inference comment, can you give an example? But I will say in advance that in many cases it makes it a lot easier to read the code when types are automatically inferred.
And my finally (for today at least), code formatting does matter to me. I remember back in 1973 when I was taking an assembler programming course at Penn State University, purposefully not formatting the assembler code well. It was very hard to follow, more so than it would have been just because it was in assembler. And yes, bracket placing is bothersome to me for a few reasons:
Many times it introduces a blank line (at the end brace) that distracts from code reabilitiy.
Having the braces the way I suggested very clearly delineates visually the block of code (to me at least), regardless of how deep the nesting is.
And yes, in most cases type inference makes code cleaner without loosing context.
As for formatting. Formatting affects readability, but it should be extremely weird to cause loss of context. And as long as context is preserved, getting used to particular formatting style is just a question of time. Developer may still hate formatting, but once he/she is get used to it, formatting is no longer an issue.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi
I think that Kotlin does help, if you don't take it to an extreme. It handles the null value issue much better than Java does, and some of the constructs allow you to focus more on the code. Another of the constructs, automatically determining the type of a variable, is also extremely helpful in facilitating not losing context.
However, some of the constructs do take you out of the context of the code so one needs to be careful.
At the risk of being controversial, there is another coding practice that I think takes people out of context when reading code, the practice of putting the starting brace { at the end of one line (with an if or while) and the end brace at the start of another line. I think that having the braces line up makes it a lot easier to follow the start and end of a block. What would make it better is if the IDEs showed braces more intelligently, i.e. as one continuous vertical brace spanning the whole block, without necessitating the need for unneeded vertical spaces. (See attached image.)
Phil
PFJ uses the same idea as Kotlin (type separation) but does not require "double" type system.
Type inference (especially how it is implemented in Kotlin) can hide part of context.
Finally, code formatting does not matter much as long as it's consistent. If bracket placing causes problems, most likely you have too deeply nested code.
Hi
I'll take a look at PFJ hopefully this week.
With respect to your type inference comment, can you give an example? But I will say in advance that in many cases it makes it a lot easier to read the code when types are automatically inferred.
And my finally (for today at least), code formatting does matter to me. I remember back in 1973 when I was taking an assembler programming course at Penn State University, purposefully not formatting the assembler code well. It was very hard to follow, more so than it would have been just because it was in assembler. And yes, bracket placing is bothersome to me for a few reasons:
Thanks for your comments!
Phil
Here is the detailed explanation with examples: 4comprehension.com/kotlin-type-inf...
And yes, in most cases type inference makes code cleaner without loosing context.
As for formatting. Formatting affects readability, but it should be extremely weird to cause loss of context. And as long as context is preserved, getting used to particular formatting style is just a question of time. Developer may still hate formatting, but once he/she is get used to it, formatting is no longer an issue.