Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^9: Tabs vs Spaces lets give this a go

by tilly (Archbishop)
on Oct 11, 2006 at 00:18 UTC ( [id://577517]=note: print w/replies, xml ) Need Help??


in reply to Re^8: Tabs vs Spaces lets give this a go
in thread Tabs vs Spaces lets give this a go

I think that C programmers are people first and C programmers second. The reasons why putting significant information first is a good thing to do have to do with human cognition, and hold just as well in C as in Perl.

However the C community as a whole is different than the Perl community, and sometimes it is better to make suboptimal choices to allow you to live within community mores. (Random example. A while ago I heard about a proposal to start lines with semicolons. I laughed, then I thought about it and decided that it is slightly better than the usual practice of putting them at the end. But it so strongly contradicts people's expectations, and there is no way I'd actually do it in practice.)

About putting commas at the start of lines, that is a habit that I got into from SQL. The problem is that in SQL it is illegal to have a trailing comma. Therefore if you put commas at the end of the line, it is easy to run into problems when extending a list. You are much less likely to run into trouble if you put the comma at the beginning of the list. I've since decided that I like formatting things the same way in Perl.

And a note about Hungarian notation. Hungarian notation is generally a bad idea in any language. Due to political reasons, Code Complete did not come out and say that as strongly as it could, but the maintainance problems that it described for that style are all accurate. (A prime example is what goes wrong is when a variable type is changed. People generally don't change the name, so now everywhere you have typed misdocumentation of the type. Wonderful.) However, that said, the existence of a type system and the reality that unexpectedly trying to cast types is often a Bad Idea in VB and C does mean that Hungarian notation carries some useful information in those languages. In Perl, of course, it is far less likely to carry any useful information.

  • Comment on Re^9: Tabs vs Spaces lets give this a go

Replies are listed 'Best First'.
Re^10: Tabs vs Spaces lets give this a go
by Fletch (Bishop) on Oct 11, 2006 at 01:06 UTC

    Joel On Software on Hungarian.

    The condensed version: Slavish use of Hungarian notations for data types (Systems Hungarian in his nomenclature; unsurprisingly another evil foisted upon the computing world from Redmond) is bad; intelligently using Hungarian to note semantic usage ("this variable is a counter"; Apps Hungarian in Spolsky's nomenclature) is what really was intended. An interesting read no mater what your Hungarian notions.

    Update: Typsplo in name corrected; thanks ysth.

      Fascinating. For once Joel makes a point that isn't obvious and I find myself agreeing with him. I guess even a stopped clock is right twice a day.

      (For the record, people tend to quote Joel a lot, I read what he has to write, then I find that I disagree. I really was surprised to see him write something that I was prepared to disagree with but then saw his point.)

      However that said, Hungarian as he describes it is not Hungarian as it is usually used.

Re^10: Tabs vs Spaces lets give this a go
by demerphq (Chancellor) on Oct 11, 2006 at 09:10 UTC
    I think that C programmers are people first and C programmers second. The reasons why putting significant information first is a good thing to do have to do with human cognition, and hold just as well in C as in Perl.

    No, sorry, I don't buy that. Where "first" is located is culturally determined, and therefore is learned. Which means that the location of signifigant information is unrelated to human cognition. If it was some kind of endemic cognitive process then you would not expect to see human writing in any other way, yet we see people writing top to bottom, right to left, left to right, and no doubt somewhere bottom to top. Heck I bet there are writing systems that go left to right, right to left on alternating lines.

    One can just as easily learn to look at the right as one can learn to look at the left. And my theory is that is exactly what C programmers do. When you see a syntax error you right scan for missing semicolons. Do that a few thousand times and it becomes second nature.

    Try it. Open a C file and scan the right side. I bet that the number of distinct characters you find there will be low. And even if you put that information at the front, you end up with stupidity, as the token at a beginning of a line isn't for that line, its for the previous line. So by trying to improve cognition by moving the tag to where you think its most likely to be observed, actually confuses things by putting the signal for a complete statement on a different line from the one it completes. And what do you do for the first and last lines? In C I guess you can put a semicolon on at the start anyway (maybe, im not sure what C would say about that if the start of a block is a declaration), but the last line? You would put a semicolon there all by itself?

    I understand the SQL trick of putting the comma at the front, its a style I dont like, but can understand it given the overall poor design of SQL. But I consider it totally inappropriate in a properly designed language like C.

    ---
    $world=~s/war/peace/g

      I'm sorry that you don't buy it, but it is true.

      If you're reading left to right, as English does, it is natural to look to the left first, and reads easier if more important stuff is there. If you're reading right to left, then conversely important stuff should be on the right. In any case if you have to scan back and forth to get important information, that is less efficient than being able to get that information in one place.

      That is the argument for putting important information on the left in Perl, and that argument holds just as well in C.

      Now it may be that people are so used to putting key information on the right in C that C programmers would need adjusting to put it on the left. Certainly when I first thought about this topic I was so used to putting it on the right that I had to think about whether to switch. But then once I did switch (largely so that my style could be consistent with SQL and JavaScript) I realized that it was superior. Compare the following:

      big_function( $argument, $another_argument. foobar( $something_long_here, $more_mess ), @more_stuff );
      versus
      big_function( $argument , $another_argument . foobar( $something_long_here , $more_mess ) , @more_stuff );
      All I did is moved punctuation What difference does that make? Well for one, the first has a minor maintainance trap that the second does not. For a more substantive issue, it is much harder to notice that there is a bug in the first version than it is in the second. And I don't care how much you're used to looking to the right for key information, that bug is always going to be a lot easier to see when the punctuation is on the left.

      So there is a real example showing a real advantage to putting punctuation on the left. Can you come up with a case where punctuation on the right leads to a concrete improvement?

      Heck I bet there are writing systems that go left to right, right to left on alternating lines.

      (Sorry for replying so late. I noticed this post of yours only now.) I was thinking that such a writing system would be very efficient: in mechanical systems you would not have carriage return and in manual ones you wouldn't have to move the pen (or whatever) across the sheet of paper (or whatever) to go to the beginning of the line over and over again. :)

        and your eye balls wouldn't need a (relatively) large fast movement at the end of each line.


        Perl is environmentally friendly - it saves trees

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://577517]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (4)
As of 2024-04-19 05:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found