http://www.perlmonks.org?node_id=889155


in reply to Re^2: What's it with Perl Syntax ?!
in thread What's it with Perl Syntax ?!

I realize that you can write bad code in any language. However, less readable code may not necessarily qualify as bad code.

The author in the article below says 'Perl is renowned for being a language where you can express complicated commands in a very small amount of space.'

http://www.builderau.com.au/program/perl/soa/Special-shortcuts-in-Perl/0,339028313,339272650,00.htm

May be good Perl programmers do not sacrifice readability for brevity. However, it would appear that Perl allows 'brevity' like no other language. I mean no offence when I say all this. All I am trying to say that when an average programmer is learning a new language, he/she may find the brevity a bit hard.

Replies are listed 'Best First'.
Re^4: What's it with Perl Syntax ?!
by ELISHEVA (Prior) on Feb 20, 2011 at 06:31 UTC

    May be good Perl programmers do not sacrifice readability for brevity.

    Good programmers (and writers) in any language adapt their writing style to circumstance.

    I think it is a common mis-perception that greater expertise means the need to use that knowledge in every circumstance. Perhaps that mis-perception is no different than the high school kid or college student who goes crazy writing essays with the longest possible words hoping to impress their teacher with their mastery of the English language? Eventually they figure out that sometimes less is more (one hopes).

    If I am writing a one liner on the command line, I might use shortcuts like you describe. No one has to read it again, including I, and it saves typing. For code that has to last a long time, I tend to avoid them. while(my $line = <STDIN>) is far more self documenting than while(<STDIN>). Additionally, those shortcut variables are fragile. They tend to get reset easily. As a result, the wise programmer transfers their value into something more stable as soon as possible.

    The situation is similar to a skilled speaker that can talk the slang of the day with their friends on the street, use simple language with their two year old child at home, and write academic papers for publication at work. It is all English (or French/Hebrew/German/etc), but oh how different.

    Where I might agree with you is that Perl's flexibility makes it more vulnerable to the same errors and mistakes we make when learning to write natural language. Java generics are obscure but you aren't likely to be responsible for reading and writing such code unless you are a fairly abstract thinker to begin with. Perl's more obscure shortcuts help with tasks even a beginner needs to do. As a result, it is a lot easier for someone learning to program to be like that high-schooler with Perl than it is with Java.

    Update: added final paragraph.

Re^4: What's it with Perl Syntax ?!
by eyepopslikeamosquito (Archbishop) on Feb 20, 2011 at 07:42 UTC

    You are using the term "readable code" without clearly defining it. I think "maintainable code" is far more important. Some of the things that help make code "maintainable" are:

    • Sound domain abstractions.
    • Wise program decomposition.
    • Highly cohesive, loosely coupled modules.
    • Descriptive, explanatory, consistent and regular names.
    • Minimizing the exposure of implementation details. Minimizing the use of global data.
    • Minimizing the scope of variables, pragmas, etc. Avoiding action at a distance.
    • Avoiding duplication (DRY).
    • Encapsulation.
    • Interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience.
    • Useful commenting and documentation.
    • Components that are testable in isolation. Comprehensive test suites.
    • Avoiding unnecessary cleverness (encapsulating and commenting it when cleverness is required).
    • Establishing a rational error handling policy and following it strictly.
    • Logging effectively. Logging enough information to trouble-shoot customer problems without the need to attach a debugger.
    • Checking the result of all file operations, API calls and external commands, and handling unexpected results.
    • Consistent code layout.
    • Avoiding "big arse" functions.
    • Avoiding magic numbers.
    Perl doesn't stop me doing any of this. Indeed, it nicely supports all of the above points IMHO. Note that a more subjectively "readable" programming language does not somehow magically prevent you from violating any of the above points. Personally, I have little interest in cosmetic issues, such as whether one prefers forced indentation (a la Python) or considers Perl's regex syntax or use of $ in variable names "ugly" or "line noise", for that is just personal (subjective) preference and has little to do with writing maintainable code.

    See also: