On 8/21/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
My preference: soft limit 80 - keep lines shorter, if it's easy hard limit ~100 - you SHALL not exceed it
coding standards are quite helpful, but cannot be applied absolutely. there are good reasons why a line of code might exceed some arbitrary number of characters, like those mentioned above. therefore i'd like to avoid a *hard* limit, where for example patches will be rejected if the line length exceeds this amount. for example, the current incantation for writing perl 5 tests for parrot goes something like this: pir_output_is(<<'CODE', <<'OUTPUT', "some lengthy and verbose test description", todo => 'write a good test someday'); due to perl 5's limitations wrt heredocs, this cannot be split onto more than one line. therefore, until the tests are rewritten in PIR, there will exist many .t files with a line length exceeding even perhaps 135 characters. rather than modifying a test header to use multiple statements which can be better formatted (which is ugly and prone to copy/paste errors,) i recommend that chars-per-line formatting not apply to test headers in .t files. further, i believe this should be generalized and extended: coding standards should be used wherever possible without requiring undue burden on the developer. therefore, i recommend that absolute words like qw<must always never shall> should not be used. also, any tools/tests/etc which enforce the standard must (and here i mean 'must') be flexible enough to deal with exceptions to the standard. ~jerry
