Your pet peeve, technical or otherwise.

[james_s]

The worst forum software by far is Discourse and it has spread like a cancer, this is one of the only forums I've used that hasn't switched, and it's no coincidence that it's the only forum I'm still active on. I cannot fathom how Discourse is so popular, it is just SO bad. There is so much fundamentally wrong with the way it works that I don't even know where to start. I really wanted to like it because there were several useful communities that use it but ultimately I ended up throwing in the towel and abandoning them. On the topic of text formatting though, when you post it has two side by side windows, and what you type in one window is duplicated in the other using the final formatting, I don't know why it doesn't just do WYSIWIG like every other text/publishing software in about the last 30 years 

[mansaxel]

Today I'm peeved about the user-hostile practice of significant whitespace. Python and YAML, I'm looking at you. What were they thinking?

Or all news sites (even the big ones like The NY Times and the Washington Post) with their narrow columns of text that remain the same size regardless of how you resize your browser window.

Or all of the forums that have migrated to software that does that too.

Sheeesh.

There actually is a reason for that. Most people read text best, most reliably
and fastest when there's no more than say 65 to 75 characters per line. 
If you increase the line length, you decrease comprehension, coherence
and reading speed.  This is why for instance IEEE and USENIX papers are
typeset in a two-column format, maximising the usage of the paper while
maintaining a short and easy to read line length.

One of many sources that discuss this: https://baymard.com/blog/line-length-readability

Counter-peeve: People who do not understand 600 years of typesetting
evolution conclusions.   

[AaronLee]

Today I'm peeved about the user-hostile practice of significant whitespace. Python and YAML, I'm looking at you. What were they thinking?

Or all news sites (even the big ones like The NY Times and the Washington Post) with their narrow columns of text that remain the same size regardless of how you resize your browser window.

Or all of the forums that have migrated to software that does that too.

Sheeesh.

There actually is a reason for that. Most people read text best, most reliably
and fastest when there's no more than say 65 to 75 characters per line. 
If you increase the line length, you decrease comprehension, coherence
and reading speed.  This is why for instance IEEE and USENIX papers are
typeset in a two-column format, maximising the usage of the paper while
maintaining a short and easy to read line length.

One of many sources that discuss this: https://baymard.com/blog/line-length-readability

Counter-peeve: People who do not understand 600 years of typesetting
evolution conclusions.   

This point brings to mind another pet peeve of mine: source code formatted to 80 columns. I understand why it was done, being in the past 80 column terminals were common. But these days, with high resolution large screen monitors, I personally see absolutely no need to force source code into 80 columns, and break up single lines of code in order to do that. It just destroys the ability to quickly scan the code.

When editing source code, I dedicate the full screen to the editor, and have over 200 columns. If I need to go over 200 columns for a single line of code, it most likely means I'm better off redoing it so that I don't have such a massive single line. With many decades worth of experience in coding, I've found time and time again that being able to scan code quickly is really the key to optimum coding/debugging speed. I just glance at a line of code and get the gist of it and then make a decision based on that (whether that line is a line of interest, or to go on to the next line). Being able to scan code rapidly and zero in on what you need, and THEN read/study carefully the line is of top priority. Breaking up lines of code onto multiple lines just totally trashes the ability to scan at the fastest possible speed. This is especially true for code which I haven't touched for many years. Quickly scanning of my code to refresh my memory and zero in on where I need to be is even more important. When my memory is rusty, neatly organized code based on single lines, proper indentation, etc., is really a must, unless I want to waste time unnecessarily.

If I'm debugging in an IDE, which has a portion of the screen to show the source code, naturally the columns are more limited, and if I need to scroll to see the whole line, I gladly trade that for the ability to have things formatted for easy scanning when I'm using my full-screen editor.

Programmers often point to the studies that say what an optimal number of characters per line is for reading, and then foolishly apply the same to coding. Coding and reading text are two completely different things, and need to be treated as such.

I get the feeling though I'm in a very small minority with this opinion. It's rare for me to see programmers who go beyond 80 or 100 columns per line, and I'm not about to tell other programmers what they should be doing. To each their own.

[mansaxel]

I get the feeling though I'm in a very small minority with this opinion. It's rare for me to see programmers who go beyond 80 or 100 columns per line, and I'm not about to tell other programmers what they should be doing. To each their own.

I'm part of the 80char movement, because I quite often edit code in a window
that is -- for some reason -- perhaps max 100 characters wide. To me, it's
more readable like that.

But, this probably comes from the fact that I'm more a systems person than
a software person, so will end up editing files in "ed" on a 80x24 terminal via
IPMI or similar...

[gnif]

This point brings to mind another pet peeve of mine: source code formatted to 80 columns.

I used to feel the same and thought it was stupid/silly to have this column width limit but as I have become more experienced as a software developer I regret not enforcing it as a standard on my projects.

For example, take this (source Looking Glass project):

Code: [Select]

      const uint64_t pending =                                                   
        atomic_load_explicit(&g_state.pendingCount, memory_order_acquire);       
      if (!lgResetEvent(g_state.frameEvent)                                       
          && !forceRender                                                         
          && !pending                                                             
          && !app_overlayNeedsRender()                                           
          && !RENDERER(needsRender))                                             
      {                                                                           
        if (g_state.ds->skipFrame)                                               
          g_state.ds->skipFrame();                                               
        continue;                                                                 
      }

vs unlimited line length

Code: [Select]

      const uint64_t pending = atomic_load_explicit(&g_state.pendingCount, memory_order_acquire);       
      if (!lgResetEvent(g_state.frameEvent) && !forceRender && !pending && !app_overlayNeedsRender() && !RENDERER(needsRender))                                             
      {                                                                           
        if (g_state.ds->skipFrame)                                               
          g_state.ds->skipFrame();                                               
        continue;                                                                 
      }

You tell me which is easier to follow if you didn't write this code? The human eye likes lists, they are easy to follow. When code gets too wide it becomes easy to miss errors in a line of code.

This is especially true for code which I haven't touched for many years.

Exactly my point here, you know your coding practices and how you would structure your conditionals, what you would name things, etc. as such scanning your own code even years later is a sinch vs someone else's code.

Enforcing a width limit not only helps prevent mistakes it also prevents developers from doing stupid things like too many layers of nested if statements:

Code: [Select]

void doSomething(void)
{
  if (a)
  {
    something
    if (c)
    {
      something
      something
      if (d)
      {
        something
        something
      }
    }
  }
}

All that nesting makes it hard to follow, especially when the function gets quite long. Now compare it to the following.

Code: [Select]

void doSomething(void)
{
  if (!a)
    return;

  something;
  if (!c)
    return;

  something;
  something;
  if (!d)
    return;

  something;
  something;
}

My current working environment for C development... If the columns were too wide, could I make efficient use of my screen space?

[gnif]

Oh and my pet peeve...

Failure for developers to use and leverage control statements like `continue`, `break`, and `return`, and obviously nested if statements where they are not needed.
Use of `malloc/calloc` for a local that would be small enough to exist on the stack. For where VLAs are not an option, `alloca` doesn't get enough attention IMO.

[AntiProtonBoy]

You tell me which is easier to follow if you didn't write this code? The human eye likes lists, they are easy to follow. When code gets too wide it becomes easy to miss errors in a line of code.

I think that's just common sense, you don't need a 80 column limitation to enforce that kind of formatting.

[gnif]

You tell me which is easier to follow if you didn't write this code? The human eye likes lists, they are easy to follow. When code gets too wide it becomes easy to miss errors in a line of code.

I think that's just common sense, you don't need a 80 column limitation to enforce that kind of formatting.

Haha, one would think, but I have seen it far too often in enterprise projects... having to horizontally scroll due to whitespace padding in .NET or Java applications is something I have had to do quite frequently due to terrible programmers.

[AaronLee]

This point brings to mind another pet peeve of mine: source code formatted to 80 columns.

I used to feel the same and thought it was stupid/silly to have this column width limit but as I have become more experienced as a software developer I regret not enforcing it as a standard on my projects.

For example, take this (source Looking Glass project):

Code: [Select]

      const uint64_t pending =                                                   
        atomic_load_explicit(&g_state.pendingCount, memory_order_acquire);       
      if (!lgResetEvent(g_state.frameEvent)                                       
          && !forceRender                                                         
          && !pending                                                             
          && !app_overlayNeedsRender()                                           
          && !RENDERER(needsRender))                                             
      {                                                                           
        if (g_state.ds->skipFrame)                                               
          g_state.ds->skipFrame();                                               
        continue;                                                                 
      }

vs unlimited line length

Code: [Select]

      const uint64_t pending = atomic_load_explicit(&g_state.pendingCount, memory_order_acquire);       
      if (!lgResetEvent(g_state.frameEvent) && !forceRender && !pending && !app_overlayNeedsRender() && !RENDERER(needsRender))                                             
      {                                                                           
        if (g_state.ds->skipFrame)                                               
          g_state.ds->skipFrame();                                               
        continue;                                                                 
      }

You tell me which is easier to follow if you didn't write this code? The human eye likes lists, they are easy to follow. When code gets too wide it becomes easy to miss errors in a line of code.

Well, I must be the odd man out, because the second is WAY easier to scan for me. When I look at code, for instance your example, I just scan that there's an if statement, and if true, it does something. I typically don't want to analyze all the conditions of the if statement when I'm scanning it. Take your first example though, and often programmers will put the opening brace at the end of the line of the last condition of the if statement, which makes it even worse. Of course I can follow code written that way, but it just takes more time for the brain (my brain at least) to process where the lines of code are, vs. the lines on the screen. Just for example, I can see/process a line I'm scanning in let's say under 100 milliseconds if it's all on one line. If it's broken into multiple lines, I first need to scan it to see where the end of the "if line" is, and then process it. That additional brain processing will maybe add another 100 milliseconds or more, and if a brace is at the end of the line, instead of on a line by itself, it takes even more time. Maybe that's just me, but absolutely quickly scanning code, and not analyzing it in any detail is a huge percent of the amount of time I spend, and I can sometimes be scanning code for several hours a day. The difference in time between the two styles, at least for me, is very significant.

Many years ago, when I first saw code where the various conditions of an if statement, or the various parameters to a function were on separate lines, of course I thought, "oh, that's easier to see each item lined up vertically". But in actual practice, it just isn't as efficient for me, because of the fact that my brain works the most efficiently by easily processing one line as one concept/statement. Certainly it is a tradeoff. If really analyzing in detail a line of code, vertically arranged parameters, etc. is faster. For scanning, where details aren't necessary, it's slower. So it depends on the ratio of scanning to analyzing.

Anyways, one key point is the indentation. When I see an if statement, etc., then the following line is indented, my brain immediately thinks the following line is to executed if the condition is true. Then it takes a bit of time to realize, "no, it's not the next line after the if statement, but it's a continuation of it." Maybe if there was a good method, such as colorization to indicate the if statement, with all of it's lines (conditions), it wouldn't be so distracting for me. But as it is, using indentation for two different purposes makes it less efficient. And maybe other programmers don't have the same issue as me if they haven't had it so engrained in their mind to do things one way (ie. the whole statement all on one line).

For the example you gave, my personal coding style for the second one would be:

Code: [Select]

      const uint64_t pending = atomic_load_explicit (&g_state.pendingCount, memory_order_acquire);
      if ((!lgResetEvent (g_state.frameEvent)) && (!forceRender) && (!pending) && (!app_overlayNeedsRender ()) && (!RENDERER (needsRender)))
      {                                                                           
          if (g_state.ds->skipFrame)
          {
              g_state.ds->skipFrame ();                                               
          }
          continue;                                                                 
      }I use parenthesis to delimit each of the conditions of the if statement. To me, it makes it easy to scan the statement and see each condition, whereas in your example they tend to run together without the parenthesis. I also ALWAYS add braces to every if statement, such as the second one. Yeah, it takes up two more lines to add those opening and closing braces, but it's just another visual cue to me to show exactly where the if block begins and ends, and also I can easily add code inside the if block later. But anyways, that's a separate issue.

This is especially true for code which I haven't touched for many years.

Exactly my point here, you know your coding practices and how you would structure your conditionals, what you would name things, etc. as such scanning your own code even years later is a sinch vs someone else's code.

Enforcing a width limit not only helps prevent mistakes it also prevents developers from doing stupid things like too many layers of nested if statements:

Code: [Select]

void doSomething(void)
{
  if (a)
  {
    something
    if (c)
    {
      something
      something
      if (d)
      {
        something
        something
      }
    }
  }
}

All that nesting makes it hard to follow, especially when the function gets quite long. Now compare it to the following.

Code: [Select]

void doSomething(void)
{
  if (!a)
    return;

  something;
  if (!c)
    return;

  something;
  something;
  if (!d)
    return;

  something;
  something;
}


Yes, the second is better. But just having a long line length available doesn't mean it should be used and an excuse for what ends up being bad coding style. In fact, I rarely use long lines. Typically the only place I use lines which go much over 100 characters is for if statements and function calls, and even then, if they become too unwieldy, then I'll modify things so that it's not the case. Of course, giving unlimited line lengths to inexperienced programmers, or programmers who've never learned proper coding style is an invitation for abuse. But there's plenty of other things besides unlimited line lengths that give rise to horrible code. In my situation, it's up to me to review the code of the software engineers who are under my supervision to see that they're practicing good coding in accordance to the standards I've specified, and if not, tell them what they're doing wrong and how to correct it. As for code written by someone outside my organization, I have no control over it, and if it's code we'll be using and need to modify a lot or frequently, we'll first convert the general format according to our standards, much of which can be done automatically, and then go over it in detail and add/adjust comments, modify bad coding style, etc.

The other time I'll go over 100 or so characters is with comments. I find it so annoying to see code that has a strict character limit per line, and see a comment that fills up one line, then on the following line has just one single last word. And comments that are written as a long paragraph, with the text just wrapping according to the limit. For normal writings, that style is fine, because it's assumed the reader will read the entire content. But for comments in code, to me it's not appropriate. Again, one line = one concept, and in the case of comments = one sentence. I try to keep the sentences of my comments fairly short, but when necessary I don't hesitate to go beyond 100 or so characters. The next sentence starts on the next line. Again, it all has to do with scanning. I read the first few words of a line of comments to see if it's applicable to what I need to know, and if so, read the whole sentence. If not, skip to the next line.

[gnif]

It certainly has a personal aspect to it and I 100% know where you're coming from because I used to write my code with the exact same styling, even the extra brackets around conditionals, and I can still work that way without difficulty still today. I also agree with comments that wrap so only one word is on the next line, that is quite frustrating.

When working with a team of developers and you can dictate the code styling standards it's not too bad, but most of my work is FOSS and the contributors are usually someone who decided to spend their free time to enhance something I built, so one can't be too picky or people will get frustrated with trying to learn your coding style (try contributing code to a project like QEMU... that's never much fun).

For my DevOps work, the 80 column limit has also helped with dodgy code in the past when a hacker has breached a website and put their malicious code 1000 whitespace characters off to the right. If you don't have line wrapping on in your editor, you won't immediately see it when checking things.

One of the first bugs I fixed in XBMC (now Kodi) was caused by a function call that would turn on AA if the 2nd last boolean parameter was true, amongst a plethora of other boolean arguments. Someone mixed up the fullscreen and AA arguments so if you run the app in fullscreen mode, it would turn on AA and run like crap. This was one of those long lines that didn't look like it had anything to do with the problem at hand and a team of 30+ developers had missed this bug for months, even resorting to writing a hacky workaround to fullscreen the app after launching it windowed as this seemed to work. This taught me the importance of breaking things up across lines, like the following where now I even comment the arguments to save on having to look up the documentation later when working on the code.

Code: [Select]

  90     XPresentPixmap(
  91       x11.display,
  92       x11.window,
  93       x11.presentPixmap,
  94       x11.presentSerial++,
  95       x11.presentRegion, // valid
  96       x11.presentRegion, // update
  97       0,                 // x_off,
  98       0,                 // y_off,
  99       None,              // target_crtc
 100       None,              // wait_fence
 101       None,              // idle_fence
 102       PresentOptionNone, // options
 103       0,                 // target_msc,
 104       0,                 // divisor,
 105       0,                 // remainder,
 106       NULL,              // notifies
 107       0                  // nnotifies
 108     );

In short, I learn't not to underestimate the utillity of splitting things up over lines.

[spsb]

Pet Peeve...

Freaking hot melt, or as professionally known as hot snot!

Yes I understand it can be helpful and I too have used it...  BUT   there really needs to be a law or perhaps a world wide authority to oversee, train and issue permits to use hot snot...   In an appropriate, clean and purposeful way..  OH and there ought to be fines or imprisonment for individuals that show blatant disregard for such authority..

Just a thought.     ..oh I feel so much better that I've said this, very therapeutic really.

[AaronLee]

It certainly has a personal aspect to it and I 100% know where you're coming from because I used to write my code with the exact same styling, even the extra brackets around conditionals, and I can still work that way without difficulty still today. I also agree with comments that wrap so only one word is on the next line, that is quite frustrating.

When working with a team of developers and you can dictate the code styling standards it's not too bad, but most of my work is FOSS and the contributors are usually someone who decided to spend their free time to enhance something I built, so one can't be too picky or people will get frustrated with trying to learn your coding style (try contributing code to a project like QEMU... that's never much fun).

For my DevOps work, the 80 column limit has also helped with dodgy code in the past when a hacker has breached a website and put their malicious code 1000 whitespace characters off to the right. If you don't have line wrapping on in your editor, you won't immediately see it when checking things.

One of the first bugs I fixed in XBMC (now Kodi) was caused by a function call that would turn on AA if the 2nd last boolean parameter was true, amongst a plethora of other boolean arguments. Someone mixed up the fullscreen and AA arguments so if you run the app in fullscreen mode, it would turn on AA and run like crap. This was one of those long lines that didn't look like it had anything to do with the problem at hand and a team of 30+ developers had missed this bug for months, even resorting to writing a hacky workaround to fullscreen the app after launching it windowed as this seemed to work. This taught me the importance of breaking things up across lines, like the following where now I even comment the arguments to save on having to look up the documentation later when working on the code.

Code: [Select]

  90     XPresentPixmap(
  91       x11.display,
  92       x11.window,
  93       x11.presentPixmap,
  94       x11.presentSerial++,
  95       x11.presentRegion, // valid
  96       x11.presentRegion, // update
  97       0,                 // x_off,
  98       0,                 // y_off,
  99       None,              // target_crtc
 100       None,              // wait_fence
 101       None,              // idle_fence
 102       PresentOptionNone, // options
 103       0,                 // target_msc,
 104       0,                 // divisor,
 105       0,                 // remainder,
 106       NULL,              // notifies
 107       0                  // nnotifies
 108     );

In short, I learn't not to underestimate the utillity of splitting things up over lines.

Yes, a lot depends on the development environment, and in your case, there's certainly a good reason for having line length limitations. In my case, all my code remains in-house, or my personal code, so I never deal with a lot of your issues. And in the few cases where a customer requires the source code, and then has their own software engineer modify it, and they modify it way outside my standards, I generally refuse to "take back" the code/project, unless I charge them a lot extra for the hassle of undoing the non-standard code.

For your example, with the ability to comment each parameter you're passing, again it's something I recognized a long time ago as being extremely useful, but conflicting with my personal philosophy of not using multiple screen lines for a single line of code. If I really needed to do something like that, I often just use a structure, and fill in the structure with separate lines of code and pass the structure as a single parameter. Yeah, I know, it likely takes up more code space and time to execute, but for me it's generally worth it for allowing me to adhere to my standards while making the code very readable. For initializing constant structures, I do use multiple lines, with the required braces, and each item on a separate line, with comments. So for me, my general rule is if there's braces, everything in between gets it's own single line (with the exception of arrays which in some cases would be tedious and meaningless to separate onto individual lines). And if it's parenthesis, then it doesn't get broken up onto separate lines.

In case anyone reading this doesn't realize it, we're referring to C language here, which might not be applicable to other programming languages.

[PlainName]

Gotta say, AaronLee, I would charge double if I had to deal with your code, and I'd still whine about it.

[AaronLee]

Gotta say, AaronLee, I would charge double if I had to deal with your code, and I'd still whine about it.

Back in the days when I was a junior software engineer, I heard lots of whining from the other members of my team about my coding style. If there's any whining done these days, they do it in secret, being I'm now the boss. It's good to be the king.

[gnif]

If I really needed to do something like that, I often just use a structure, and fill in the structure with separate lines of code and pass the structure as a single parameter.

100%, this is what I would do also, in this case, it's an external library for which we have no control over the prototype for.

[AaronLee]

While on the subject of pet peeves, related to C language, here's a few more of mine.

1. Abbreviations in variable names. Unless it's a totally standard abbreviation, you might have trouble remembering your own abbreviations, and certainly will not remember someone else's abbreviation if it doesn't match what you'd choose. This obviously is a problem when wanting to search for a variable, or using a variable but not remembering the exact spelling. And often the abbreviation leads to ambiguity. Perhaps not the best example, but 'temp' used in software dealing with temperature. Does 'temp' mean temporary or temperature? I've lost countless hours over the years trying to remember the correct abbreviation, or looking at someone else's code and scratching my head as to what the abbreviation means.

2. Too short of names for variables. Ok, 'i' for some index is fine, or 'x' or such for some temporary variable that's immediately then used again. But for meaningful variables, don't use some short name that doesn't adequately describe what it's purpose is. Yes, if the variable name doesn't adequately describe it, but you comment it well where it's defined, I can look it up, but that wastes time. Sure, it takes extra time to type out a long variable name, but the code is so much more readable like that, and saves time in the long run.

3. Underscores in variable names. This one might sound strange, but I disliked having to stretch my finger to press the underscore, as it's commonly for separating words in variable names. These days I have a keyboard which I can totally customize, and put the underscore on an easily accessible key, such as Shift-Space, if I wanted to. So I guess it's no longer a pet peeve, but I got used to over the years just capitalizing the first letter of each word in a variable name in order to distinguish words, rather than the underscore. For macros, which I use all caps, I do use the underscore. So not using underscores in variable names also is another way to emphasize that it's a variable and not a macro, and to my eyes just looks cleaner.

4. Lack of a standardized line of comments at the top of each function, specifying the name, description, parameters, return value, etc, along with some instantly easily recognizable way of separating those comments from the general code, such as a full line of equal signs, dashes, asterisks, or whatever you like at the top/bottom of the header. When I'm scanning code in a file from top to bottom, and get to a function, then determine I've seen enough, I want to quickly jump to the next function, which scrolling down quickly until I see that instantly recognizable header allows me to do that with the greatest efficiency. A function without any header on top can easily be missed when trying to scroll very quickly through a file. Not to mention, the header naturally is great documentation for knowing what the function does and how to use it.

5. Lack of whitespace to separate things. There's no limitations these days for the storage size of source code. Nor noticeable difference in compile times by adding as much whitespace as needed to make things clear. Being whitespace is basically free, use it as much as is needed to make your code more readable. The example are endless, but for one:

for (i = 0; i < 10; i++)

is much more instantly readable to me than:

for(i=0;i<10;i++)

Those were just the first five off the top of my head, but I'm sure there's a very long list of coding pet peeves if I thought about it.

[DrG]

I have long held a pet peeve against the misuse of the word random, especially in professional contexts, but also everywhere else.

If a number between 1 and 100 is chosen at random, it means to me that every number from 1 to 100 had an equal probability of being chosen.

If a shirt to wear is chosen at random, it means that every shirt had an equal probability of being chosen. If I chose a shirt to wear for some unspecified reason, some unknown or unclear reason or it struck my fancy at the moment, it does not mean that it was chosen at random.

If some woman came up to me and starting talking politics at the mall, it does not mean that it was some random woman.

Making a choice without some specified method or conscious decision does not make it a random choice.

An understanding of what random does and does not mean is an integral part of all inferential statistics that I use and deserves accurate use in many professional activities and in common and casual conversation. It is a very important concept and, as such, it should be treated as a reserved word. Instead, you can read dictionary definitions for the word that are explicitly wrong.

There is no reason to part from the accurate use of the word because it is somehow convenient or one does not know any better and, further, the rationalization of “you know what I mean” is particularly annoying because you don’t know what you mean.

[PlainName]

If some woman came up to me and starting talking politics at the mall, it does not mean that it was some random woman.

What word would you use instead?

The OED suggests 'at random' means "without method or conscious decision", which is typical of the rest of the definitions. It is only in statistics where the meaning is "goverened by or involving equal chances for each item".

It would seem that you are using the definition for one field in another. Kind of like 'wet' can have multiple meanings which are all OK and sensible in the right context, but a mess (and no doubt worth a rant) if used in the wrong field.

[TimFox]

In statistics, a random distribution is one that follows a given probability density function (which need not be flat) and where the total is one (everything must be somewhere).

[IDEngineer]

...which reminds me:

"If you have a 50-50 chance of guessing something right, there's a 90% chance you'll guess wrong."

Statistics can be a cruel taskmaster.

[Bassman59]

I get the feeling though I'm in a very small minority with this opinion. It's rare for me to see programmers who go beyond 80 or 100 columns per line, and I'm not about to tell other programmers what they should be doing. To each their own.

I'm part of the 80char movement, because I quite often edit code in a window
that is -- for some reason -- perhaps max 100 characters wide. To me, it's
more readable like that.

But, this probably comes from the fact that I'm more a systems person than
a software person, so will end up editing files in "ed" on a 80x24 terminal via
IPMI or similar...

I'm also in the 80-character camp but I realize that I'm not using punch cards and I should probably just stop.

But now that I have this nice 4k monitor at work (and the 5k on the iMac at home) I've gotten quite used to having multiple emacs windows side-by-side, each a bit more than 80 characters wide. I can fit four of them on the screen!

[PlainName]

But now that I have this nice 4k monitor at work (and the 5k on the iMac at home) I've gotten quite used to having multiple emacs windows side-by-side, each a bit more than 80 characters wide.

Exactly this. Since I ran Brief under DOS I've always had two or more edit windows side-by-side.

[AaronLee]

But now that I have this nice 4k monitor at work (and the 5k on the iMac at home) I've gotten quite used to having multiple emacs windows side-by-side, each a bit more than 80 characters wide.

Exactly this. Since I ran Brief under DOS I've always had two or more edit windows side-by-side.

Now there's a name (Brief Editor) that I haven't heard, nor even thought about for a very long time. When I first saw it for sale (back in the good old DOS days), I thought "why would anyone pay that much for just an editor", but then realized how much money it could save by improving productivity.

[CatalinaWOW]

I have long held a pet peeve against the misuse of the word random, especially in professional contexts, but also everywhere else.

If a number between 1 and 100 is chosen at random, it means to me that every number from 1 to 100 had an equal probability of being chosen.

If a shirt to wear is chosen at random, it means that every shirt had an equal probability of being chosen. If I chose a shirt to wear for some unspecified reason, some unknown or unclear reason or it struck my fancy at the moment, it does not mean that it was chosen at random.

If some woman came up to me and starting talking politics at the mall, it does not mean that it was some random woman.

Making a choice without some specified method or conscious decision does not make it a random choice.

An understanding of what random does and does not mean is an integral part of all inferential statistics that I use and deserves accurate use in many professional activities and in common and casual conversation. It is a very important concept and, as such, it should be treated as a reserved word. Instead, you can read dictionary definitions for the word that are explicitly wrong.

There is no reason to part from the accurate use of the word because it is somehow convenient or one does not know any better and, further, the rationalization of “you know what I mean” is particularly annoying because you don’t know what you mean.

So you are saying that the choices from your selection process do not have a uniform probability distribution they are not random?  Certainly limits whole books full of statistical tools.  And means that many natural processes are not random.  Things like Johnson noise. 

[DrG]

I have long held a pet peeve against the misuse of the word random, especially in professional contexts, but also everywhere else.

If a number between 1 and 100 is chosen at random, it means to me that every number from 1 to 100 had an equal probability of being chosen.

If a shirt to wear is chosen at random, it means that every shirt had an equal probability of being chosen. If I chose a shirt to wear for some unspecified reason, some unknown or unclear reason or it struck my fancy at the moment, it does not mean that it was chosen at random.

If some woman came up to me and starting talking politics at the mall, it does not mean that it was some random woman.

Making a choice without some specified method or conscious decision does not make it a random choice.

An understanding of what random does and does not mean is an integral part of all inferential statistics that I use and deserves accurate use in many professional activities and in common and casual conversation. It is a very important concept and, as such, it should be treated as a reserved word. Instead, you can read dictionary definitions for the word that are explicitly wrong.

There is no reason to part from the accurate use of the word because it is somehow convenient or one does not know any better and, further, the rationalization of “you know what I mean” is particularly annoying because you don’t know what you mean.

So you are saying that the choices from your selection process do not have a uniform probability distribution they are not random?  Certainly limits whole books full of statistical tools.  And means that many natural processes are not random.  Things like Johnson noise.

No, I am not saying that at all. That is why you could not point to where I said such in my post. It's just that simple and you telling me what I said does not mean that I said it, no matter what you want to believe. Nor does you deciding to interpret what I said in some manner that you can argue about mean that I said it - that is, I don't think what I wrote needs your your interpretation. I stand by what I said, I am not backing down, changing it or otherwise suggesting that it needed to be written more clearly.

What it does mean, however, is that I am not going to take your bait. Nice try and all that but you see it is MY pet peeve and I don't need for you to agree with it, and I am not dismayed that you (or really anyone) disagrees with it, does not understand it, or even verbally engages in precisely what I am peeving about -or not.

If I spent my next 1000 posts trying to convince you otherwise, I feel certain that I would fail because I don't believe that you have tried to understand what I wrote, you just didn't like how it sounded so you decided that I must have said something else and something that you could argue about, hence the distinctly underwhelming "so you are saying" ploy.

If you (or anyone) truly wants to pursue this, then take my post, one sentence at a time, and clearly state why you thing it is wrong. Don't give me this..."so you are saying" and than insert some ridiculous interpretation - you are better than that.

Use what I actually wrote, so:

If a number between 1 and 100 is chosen at random, it means to me that every number from 1 to 100 had an equal probability of being chosen. Do you disagree with that? - if no, move on to the second sentence. If yes, explain to me why what I said in that sentence is wrong or why you don't agree with it even if you don't think it is necessarily wrong.

Can you actually do that? If yes, then do it and if it is a sincere attempt, I will respond.