re: Is This Snowflake Code? VIEW POST

FULL DISCUSSION
 

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 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:

my @array ;
my $x = 0 ;
while ( my $line = <DATA> ) {
    chomp $line ;
    $line =~ s{\D}{ }mxg ;
    my @line = split m{|}mx, $line ;
    for my $y ( 0 .. 8 ) {
        my $digit = ' ' ;
        $digit = $line[$y] if defined $line[$y] ;
        $array[$x][$y] = $digit ;
        }
    $x++ ;
    }

@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.

 

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.

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.

code of conduct - report abuse