Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Don't post bad code!

by afoken (Canon)
on Sep 26, 2016 at 20:46 UTC ( #1172668=perlmeditation: print w/replies, xml ) Need Help??

The thread Declaring and checking content of variables with consecutive names and especially the answer Re: Declaring and checking content of variables with consecutive names triggered this meditation.

There is nothing special about this thread or this answer, it's just one of those FAQs (in this case "How can I get variable variable names"). People explain how to do the job properly, and some other people can't resist showing that there is a way how to force perl into using the stupid variant. I vagely remember threads where people tried to find even more stupid ways to "solve" a cleanly solveable problem.

Yes, we can force perl into doing the most stupid things. Yes, it's cool to know how to mess with the inner workings of perl. But no, we should not show beginners the most dirty ways first. Not even with warnings not to use the dirty ways in production code. "Just do as I say, don't do as I do" is no good motto, not for teaching beginners.

Why? Because there are lots of beginners out there, who either don't have time to or are unwilling to learn how to use perl. They just want fast results, they don't care about maintainability or improving their skills. Imagine what happens when they get ten answers linking to FAQs, HOWTOs, documentation, or showing examples of the right way, but require a little bit of thinking; and one or two answers showing how to abuse perl into the way they are currently thinking.

"There is nothing humans would not do to avoid thinking."
-- Found on a pinboard in a computer laboratory in my univerity

This way, bad practices propagate, resulting in crappy perl scripts.

Let's make it hard for the unwilling and the people in a hurry to find bad code, bad examples. Posting sane examples is good, improving a code example posted is even better.


But what about golf?

Perl golf is fun, true. Replacing pages and pages of code with 20 characters of "line noise" with the same result is deeply impressive. But do we have to show our golf skills in beginner threads? I don't think so. Create a new thread, link to the beginner's thread, and name it "Golf Challenge". Or at least start a golf posting by explaining that this is not a real answer, but a golf challenge for the experts.


Are one-liners bad?

(A meditation in a meditation)

It depends. Short one-liners for one-time use are ok. But for anything more complex than one or two, maybe three explicit instructions (not counting the implicit loops in perl -p and perl -n) should be in a script. And if the one-liner is to be reused, it should instead be a script, too.

Why?

  • One-liners require that you remember quite complex "line noise". So you very likely store them in a file. What's the difference to using a real script? It's just harder to use, as you need to copy-and-paste.
  • Quoting rules differ with different shells (and different operating systems), so you need to adapt the one-liners, especially the arguments to perl -e and perl -E, to the shell currently in use. Scripts don't have this problem.
  • Scripts can have nice names. cleanup-foo is easier to remember, easier to type, and shows the intention more clearly than perl + 10 perl command line options + -e plus 80 characters of "line noise" in quotes differing from shell to shell.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re: Don't post bad code!
by Your Mother (Bishop) on Sep 26, 2016 at 21:14 UTC

    Well, those posting bad code don’t know the difference. Those believing it to be sound advice are starting a journey toward discernment in a world absolutely heterogeneous in quality and value and they will have to take some lumps along the way or never break out of the inner circle of Dunning–Kruger. It’s not always in their interest to protect them. Attempts at process, rules, or dogma to enforce quality often have unintended consequences and like most crime/“crime” the admonishments are ignored by those they would help or correct while already understood and followed by the rest.

    I can see a code post here by afoken or AnomalousMonk or Corion or, or, or… and know it to be good or, at the least, worth examining seriously and with all benefit of the doubt. New users and Anonymous Monk get a couple kilos of skepticism. I believe in best practices and would probably cite this (update: meaning your OP) post in a discussion as something worth considering. So… I’m not sure I have a point except maybe: trying to prevent crap is the fount of quite a lot of crap in the end.

      Well, those posting bad code don’t know the difference.

      My meditation lacks the word "intentional": It is about intentionally posting bad code. (See Re^2: Don't post bad code!)

      And I think people who manipulate the symbol tables instead of showing how to use arrays or hashes do know the difference.

      Those [...] never break out of the inner circle of Dunning–Kruger. It’s not always in their interest to protect them.

      Good point. I've met two or three people from the innermost circle in my life, and I should have remembered how much I wished they would do a much less harmfull job (like self-moving ballast or park bank pre-warmer) at the other end of the world. Not to mention tens of people with a little bit less of D-K.

      But still: Should we feed them with bad practices?

      Attempts at process, rules, or dogma to enforce quality often have unintended consequences and like most crime/“crime” the admonishments are ignored by those they would help or correct while already understood and followed by the rest.

      I’m not sure I have a point except maybe: trying to prevent crap is the fount of quite a lot of crap in the end.

      I don't think that allowing bad code will sort out the D-K people. The crap they produce is much too often considered "good enough", some times for years and tens of years. It's part of their job security, no one except them has even the slightest clue of what happens in their code.

      <:Update>

      Design and code review (at peer level) are an excellent way of improving quality. Unfortunately, it requires any writer to accept a lot of critic from the peers. The most important part is to understand that critic is about improving quality, not about the person.

      </Update>

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Don't post bad code!
by Discipulus (Abbot) on Sep 26, 2016 at 22:55 UTC
    dear afoken, you, as usual, are right.

    Every point you touch in the above meditation is correct and sounds of your will to help people learning Perl.

    But to learn is a matter of intelligence and intelligence is matter of choice (intelligere intus/inter + legere as in "be able to choice among" ).

    Your will to teach a better Perl does not make this monastery a school.

    The monastery is a reflection of the reality: "who want to speak about Perl? come on entrance is free" is a wide call for every type of coders and even no coders at all!

    Our (mmh more on me later..) goal is to offer our solutions or opinions and underline well in red which are good and wise answers; recently a bunch of discussions pointed to the necessity to show in better way good answers and good coders.

    The voting system and Level of monks helps a little in this way but somehow can be a guidance for newcomers. But is up to the newcomer to understand what he choice to ear (and to copy in his program).

    Many people here around are not professional programmers; sysadmins, net people, hobbyst coders, amateurs, curious ones.. many of us have no such thing called production code

    I did not say this is good or wrong; is a fact.

    I entered the IT in a very tangential way, I stumbled on Perl and i liked it. I immediately appreciated PerlMonks as a cave of true gems. After years spent reading I have good list of monks which post I look with attention but sometimes I can tell good and wise answers from Anonymous ones too.

    When there is a discussion about something I know, even little, If I can show another way, i take my slice of freedom and I post something; if it is wrong and downvoted and some big monks explain why my contribution was no wise.. is always a way to teach and to learn, for me and others. I can produce many examples but one for all is Find 30 days from today's date

    I answered with my personal examples because in many, if not all, point you touch I'm guilty, I was and I will.

    TIMTOWTDI is a Perl foundamental too and is educative even to know that some task is doable with a oneliner. I recently posted many oneliners because i had fun writing them, more fun than watching tv. I think too that oneliners are somehow irreverent in respect to the programming in itself: obviously if someone fond his critical application on my idea of ten days ago using the above oneliner is a fool as fool is who write a complete program just to know which range of days in logs need to analyze.

    Smart snippets, oneliners, are not wise? If they provoke challenge and fun so they can be a big boost while learning Perl.

    Golf code in beginner thread? I can assure you from my experience that is completely unharmfull: in the past I looked at such code more like to some kind of ASCII art, like Linus at russian names.

    The orrible hat of a turist in front of you does not erase your souvenir of Colosseo.

    best regards



    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
      to learn is a matter of intelligence and intelligence is matter of choice

      Good point. But as you wrote:

      Our [...] goal is to offer our solutions or opinions and underline well in red which are good and wise answers; recently a bunch of discussions pointed to the necessity to show in better way good answers and good coders.

      It is hard for a beginner to estimate the quality of a posting. The existing voting system does not help here, because you can't see the votes a posting has collected. You need to vote first. Initiates can't vote at all, Novices can vote only twice, so they can get a quality estimate for only two answers. And of course, you need to find and study the voting documentation (e.g. Voting/Experience System) first, while your real problem waits for a solution.

      So yes, an improved voting / rating system would help beginners.

      When there is a discussion about something I know, even little, If I can show another way, i take my slice of freedom and I post something; if it is wrong and downvoted and some big monks explain why my contribution was no wise.. is always a way to teach and to learn, for me and others.

      My meditation is about intentionally posting bad code (sorry, missed that important word in the meditation), not about posting "accidentally" bad code.

      I can produce many examples but one for all is Find 30 days from today's date

      Easy: perl -E 'sleep 30*24*60*60; say scalar localtime' ;-)

      Smart snippets, oneliners, are not wise? If they provoke challenge and fun so they can be a big boost while learning Perl.

      Right. But it requires a beginner willing to learn. So yes, it's a good thing.

      Golf code in beginner thread? I can assure you from my experience that is completely unharmfull: in the past I looked at such code more like to some kind of ASCII art, like Linus at russian names.

      I doubt that. If you start with perl, even good code looks like ASCII art or line noise. Especially if perl is your first language. For me, Perl was language number 5 or 6, so I could see structures even without knowing the language. MUMPS was number 15 or 20, and even if it looked like a cat ran several times over an old typewriter, it took me just a few hours to understand the basics and a few weeks to write significantly better code than my instructor. Beginners don't have that amount of experience.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Don't post bad code!
by haukex (Chancellor) on Sep 27, 2016 at 09:56 UTC

    Hi Alexander,

    I agree with many things in your meditation. I do want to provide some counterpoints to a few things.

    But no, we should not show beginners the most dirty ways first.

    I absolutely agree, if the emphasis is on "first". But I think it's a little unfair to pick on 1172628: it was posted several days after two very good replies showing the better way to accomplish the OP's goal, it does contain a disclaimer, and I'm pretty sure it'll stay near the bottom of the page. The only thing I felt missing in that node is a discussion of strict, which I have now added in a reply.

    ... Not even with warnings not to use the dirty ways in production code.

    I disagree: If a question is first answered with the "best practice" way, then I think that posting the one-liner or "bad" way afterwards - with a prominent disclaimer - isn't a bad thing. People who are just looking for a quick answer to copy-and-paste into their script (of whom there are many) will use the first thing they find, which will usually be the first and/or most-upvoted answers, especially since the relatively recent change that replies are sorted "best first" by default. But threads are read by many more people, and those who actually want to learn Perl (hopefully including the OP) can scroll down, and they will learn something interesting.

    People will always find bad code all over the 'net and use it. Just the other day I came across a blog posting showing an arguably bad snippet of Perl code, and the only indication that there was something wrong with it was if you scrolled down into the comments section (which had a tiny font). So instead, I think that showing both the right way(s) and the "wrong" way with a prominent disclaimer will help people to differentiate between the two, and to learn why something is "bad".

    Note that I'm putting "bad" and "wrong" in quotes here because I'm a fan of TIMTOWTDI, while at the same time I think that guiding people to using the best practices is also a Good Thing.

    There lots of threads where I see replies and think "I wouldn't have posted that", such as the many cases where people get code written for them where I happen to feel they haven't shown enough of their own efforts. But getting frustrated that I can't control what other people post is not the answer :-)

    Instead I like the system that is already in place: Replying to nodes that contain "bad" code, and the voting system. Monks who truly want to contribute will quickly learn that posting replies that adhere to best practices is appreciated by more people. Your meditation is also good reminder of the "best practices of posting".

    Regards,
    -- Hauke D

      I think it's a little unfair to pick on 1172628: it was posted several days after two very good replies showing the better way to accomplish the OP's goal, it does contain a disclaimer,

      Yes, maybe. It is not the best example for a "bad code" posting, and I know that there are worse postings. But as I wrote: It is the posting that triggered my meditation. It was the straw that broke the camel's back.

      There lots of threads where I see replies and think "I wouldn't have posted that", such as the many cases where people get code written for them where I happen to feel they haven't shown enough of their own efforts. But getting frustrated that I can't control what other people post is not the answer :-)

      (I'm not frustrated.)

      Instead I like the system that is already in place: Replying to nodes that contain "bad" code, and the voting system. Monks who truly want to contribute will quickly learn that posting replies that adhere to best practices is appreciated by more people.

      Very good point. It does not require any changes to the monastery code, and everyone can contribute. Simply by posting "Don't do that. It's the path to the dark side. 'Once you start down the dark path, forever will it dominate your destiny.' -- Yoda" Yoda quote optional. ;-)

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re: Don't post bad code!
by BrowserUk (Pope) on Sep 26, 2016 at 21:39 UTC

    Just for counterpoint.

    The typical solution to the symbolic reference problems, is: "Use a hash"; but symbolic references use a stash, a symbol table hash.

    The only real difference between symbolic references and hashes, is an extra level of indirection.

    Oh, and the fact that use strict effectively disables autovivification in stashes; which is a power only relatively newly granted to hashes by autovivification

    "Bad code" is only bad code if it is used badly; used correctly, it can be a very useful, and powerful asset.

    Blanket bans (on anything) just encourage ignorance.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Don't post bad code! (Dont worry about it)
by Anonymous Monk on Sep 27, 2016 at 01:33 UTC

    Hi

    Why? Because there are lots of beginners out there, who either don't have time to or are unwilling to learn how to use perl.

    They just want fast results, they don't care about maintainability or improving their skills. Imagine what happens when they get ten answers linking to FAQs, HOWTOs, documentation, or showing examples of the right way, but require a little bit of thinking; and one or two answers showing how to abuse perl into the way they are currently thinking.

    Let's make it hard for the unwilling and the people in a hurry to find bad code, bad examples. Posting sane examples is good, improving a code example posted is even better.

    Hi

    Don't worry about it new monk :)

    You can't protect people from themselves, the internet (even perlmonks) is full of bad code

    Don't give it a second thought

    Many of us have already changed the way we respond many times ...

    we grow, we learn, we change our replies

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1172668]
Approved by Corion
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (8)
As of 2019-07-18 15:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?