As a personal taste, i do find the second style braces to be harder to read than the first one, just like the others before me have stated. I find that it's easier to see a closing brace and the corresponding block of code if it's idented the same as the line on which the opening brace is. But still, after a few minutes of getting used to this, IF this identing style is consistent throughout your code, then i can adapt to it and have little to no problem reading your code. By the way, Python is such a language that forces this on us, as there are no opening/closing braces, so we have to look at identing to see blocks of code.
What i find to be suboptimal, if i may say so, and i see this on 99% of the source code written by other programmers, is not using naming conventions on variables & objects. For example, taking your above code, i would never ever write something like my $outcount = 0 ;, instead i would name that variable $nOutCount, so i can know imediately, when i look at it, that it's an integer variable (the n in front). Similarly, i wouldn't write my $line = <DATA>, but i would give it a name of $strLine, so i can clearly see it's a string variable. Same thing goes for every other data type. Yes, i know that in these kinds of languages, variables could change their type pretty easily, however i don't think anyone actually does this as it's verry confusing, so knowing what type of variable it is, without following the code, is a great benefit.
I’ve seen these attempts to make yourself comfortable in dynamically types languages, specifically PHP. I find them irritating at most, as you dont KNOW which type cariable will have at runtime (and if it will change it). So this prefixing gives you nothing but false-confidence. Is it somehow different in Python (does it infer type on init, but doesnt allow to change one, like Golang?)
Similarly, when I'm dealing with other people's code, or maintaining things that are not exclusively mine, I am happy to work to that style. (Within parameters; I am refactoring a 2.5 KLOC program that not even the original developer felt comfortable fixing, and I am not respecting it's established style one bit.)
My problem is that the opening brace is not at the same line.
sub sample_subroutine {
...
}
Wouldn't it be more like?
sub sample_subroutine {
...
}
???
Unless you go full GNU-style...
sub sample_subroutine
{
...
}
Which makes it seem to me like sample_subroutine dropped the opening brace like Sonny dropped the gun in the restaurant scene in The Godfather.
My formatting is consistent, because of perltidy. I have a keystroke aliased in vim, and use the VS Code to allow Perl formatting (although I am convinced it is not using the installed perltidy executable, even though I have told it the path.)
My first degree is in Journalism, and many evenings doing full-page layout has given me a sensitivity to readability, but I don't want one person's view of readability forced upon me, especially when it can hide productivity bombs.
(First time I touched Python, in 2000 or so, it was indented with tabs, and someone -- maybe me, maybe the source, maybe a solar flare while in transit -- put a space before a tab, making the code non-functional and making my hello world experience a couple hours of frantic debugging. I know this would not happen with Python 2.7 or 3.5, but it made me hate Python for 20 years. Now, I mostly hate Python packaging and how it routinely breaks my toys, but that's another matter.)
On the subject of Force and One True Style, I was recently made aware that Go will reformat your code on compile, leading to swag that says GO FMT yourself.
I ... um ... yeah.
But thanks for the time you spent reading and responding. While I may not agree with your points, they are well-considered and well-expressed.
I looked at it in the 1990s, hearing it was Microsoft house style, and decided that Perl kinda had this with the sigils; $, @, % and &. I get the point of it, but I didn't see it as adding value. I don't see anything gained by my $fpPi = 3.14159. because you know what Pi is and how it is used. (Incidentally, that could now be my $fpπ = 3.14159.)
The problem of "what kind of thing IS this variable" is lessened by not having code blocks larger than an editor window, so that you can see most everywhere $line is used.
@array is a two-dimensional array, and $x and $y represent positions within. $digitcould be better-named, because it could be a single digit 1-9 but it could be a space, because I'm avoiding undefs. Is it better as $chDigit? But the whole thing is eleven lines and the only thing that is used after this is @array. (Which is too generic a name, but I couldn't think of a better one when I was coding it. @puzzle? @chPuzzle? @arrchPuzzle?
Currently, I'm doing a lot more with references, both arrayrefs and hashrefs, because I'm much more likely to pull from JSON or SQL, and the tools I have give me references, and I think that $objrefUser->{ uintID } would not give me any benefit.
There are places where it would make sense, but since I don't work in those places, I get why I am in the 99% on this one.
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.
Hello Dave,
As a personal taste, i do find the second style braces to be harder to read than the first one, just like the others before me have stated. I find that it's easier to see a closing brace and the corresponding block of code if it's idented the same as the line on which the opening brace is. But still, after a few minutes of getting used to this, IF this identing style is consistent throughout your code, then i can adapt to it and have little to no problem reading your code. By the way, Python is such a language that forces this on us, as there are no opening/closing braces, so we have to look at identing to see blocks of code.
What i find to be suboptimal, if i may say so, and i see this on 99% of the source code written by other programmers, is not using naming conventions on variables & objects. For example, taking your above code, i would never ever write something like my $outcount = 0 ;, instead i would name that variable $nOutCount, so i can know imediately, when i look at it, that it's an integer variable (the n in front). Similarly, i wouldn't write my $line = <DATA>, but i would give it a name of $strLine, so i can clearly see it's a string variable. Same thing goes for every other data type. Yes, i know that in these kinds of languages, variables could change their type pretty easily, however i don't think anyone actually does this as it's verry confusing, so knowing what type of variable it is, without following the code, is a great benefit.
Cheers!
I’ve seen these attempts to make yourself comfortable in dynamically types languages, specifically PHP. I find them irritating at most, as you dont KNOW which type cariable will have at runtime (and if it will change it). So this prefixing gives you nothing but false-confidence. Is it somehow different in Python (does it infer type on init, but doesnt allow to change one, like Golang?)
Re: Your first paragraph
Similarly, when I'm dealing with other people's code, or maintaining things that are not exclusively mine, I am happy to work to that style. (Within parameters; I am refactoring a 2.5 KLOC program that not even the original developer felt comfortable fixing, and I am not respecting it's established style one bit.)
My problem is that the opening brace is not at the same line.
Wouldn't it be more like?
???
Unless you go full GNU-style...
Which makes it seem to me like sample_subroutine dropped the opening brace like Sonny dropped the gun in the restaurant scene in The Godfather.
My formatting is consistent, because of perltidy. I have a keystroke aliased in vim, and use the VS Code to allow Perl formatting (although I am convinced it is not using the installed perltidy executable, even though I have told it the path.)
My first degree is in Journalism, and many evenings doing full-page layout has given me a sensitivity to readability, but I don't want one person's view of readability forced upon me, especially when it can hide productivity bombs.
(First time I touched Python, in 2000 or so, it was indented with tabs, and someone -- maybe me, maybe the source, maybe a solar flare while in transit -- put a space before a tab, making the code non-functional and making my
hello world
experience a couple hours of frantic debugging. I know this would not happen with Python 2.7 or 3.5, but it made me hate Python for 20 years. Now, I mostly hate Python packaging and how it routinely breaks my toys, but that's another matter.)On the subject of Force and One True Style, I was recently made aware that Go will reformat your code on compile, leading to swag that says GO FMT yourself.
I ... um ... yeah.
But thanks for the time you spent reading and responding. While I may not agree with your points, they are well-considered and well-expressed.
Re: Your second paragraph
That would be Hungarian Notation, correct?
I looked at it in the 1990s, hearing it was Microsoft house style, and decided that Perl kinda had this with the sigils; $, @, % and &. I get the point of it, but I didn't see it as adding value. I don't see anything gained by my $fpPi = 3.14159. because you know what Pi is and how it is used. (Incidentally, that could now be my $fpπ = 3.14159.)
The problem of "what kind of thing IS this variable" is lessened by not having code blocks larger than an editor window, so that you can see most everywhere $line is used.
This also gets to convention. Repeating the read:
@array is a two-dimensional array, and $x and $y represent positions within. $digit could be better-named, because it could be a single digit 1-9 but it could be a space, because I'm avoiding undefs. Is it better as $chDigit? But the whole thing is eleven lines and the only thing that is used after this is @array. (Which is too generic a name, but I couldn't think of a better one when I was coding it. @puzzle? @chPuzzle? @arrchPuzzle?
Currently, I'm doing a lot more with references, both arrayrefs and hashrefs, because I'm much more likely to pull from JSON or SQL, and the tools I have give me references, and I think that $objrefUser->{ uintID } would not give me any benefit.
There are places where it would make sense, but since I don't work in those places, I get why I am in the 99% on this one.