Hacker News Reader

Comment by cmccabe | Hacker News Reader

It's not about the screen or the computer; it's about the primate sitting in front of it. Long lines are unreadable. That's why newspapers have multiple columns.

View on HN

Sure. But sometimes the strict limit forces you to do things that are worse than just leaving the long line, simply to comply with some automated coding style enforcement. For example sometimes you have to break up strings into separate parts and wrap the last argument following them to it's own line for readability... Even if the same arguments pattern if used all over the project (so one line would be more recognisable / readable). So you get 3 lines that are worse (for example) to grep than one line just because it would have 85 characters otherwise.

Long lines are unreadable, enforced short lines are unnatural, common idea of the best judgement doesn't exist. :(

Newspapers can deal with this by squeezing words / letters together, or allowing more space in some lines to make the text align better. Code using monospace font can't do the same.

Using grep with strings that span multiple lines is not a big deal. Use the -A and -B flags, as well as --with-filename.

Widely agreed-on code standards do exist. Usually they are either 80 or 100 characters per line.

This is not always true:

    log.msg("error with " +
            "some description")
    
    grep "error with some description" ...

Yes, there are standards for coding. They are usually 80 or 100 characters. And each one has a different way of handling the wrapping cases, splitting strings, wrapping values (parens, line join with \, concatenation, etc.)

You can use something like this:

  grep --with-filename -A 3 error $FILES | grep -C 3 description

If that's not elegant enough for you, there are even tools like pcregrep that can do multiline matches. Don't uglify the code because of easily solved tool problems.

Reply on news.ycombinator.com