On Fri, Dec 18, 2009 at 8:28 AM, Krzysztof Halasa <khc@xxxxxxxxx> wrote:
> Valdis.Kletnieks@xxxxxx writes:
>
>> Yeah, but I respectfully submit that if the regexp '^\t{6}' matches a non-
>> continuation line, it's probably in its rights to whinge.
>
> Yes, but don't make it a hard error, only a suggestion that something is
> probably really wrong.
>
>> fs/reisersfs/do_balan.c, lines 460-477 (note: 3 leading tabs elided)
>>
>> leaf_paste_entries(&bi,
>> n +
>> item_pos
>> -
>> ret_val,
>> l_pos_in_item,
>> 1,
>> (struct
>> reiserfs_de_head
>> *)
>> body,
>> body
>> +
>> DEH_SIZE,
>> tb->
>> insert_size
>> [0]
>> );
>>
>> Yes, that used to be 24 more columns to the right. Gaak.
>
> Precisely. It's a clear show of the damage hard rules like that do.
> I can't even tell how the code should be fixed and if the simple merging
> would do, since I can't really imagine how it would look like :-)
I think you're missing the point, there is no simple fix for this sort
of formatting problem. The 80 column hard limit didn't cause this
mangling, someone applying an obviously misguided quick fix to the
too-long line caused the problem. The appropriate thing to do when
checkpatch tells you that a line is too long isn't necessarily to chop
the line into pieces. The appropriate thing to do is look at the
surrounding context and determine what the underlying problem is. In
this case Bart pointed out that quite a lot of the overly-complex
parameter could be reasonably moved to a helper macro, and the
too-long surrounding function should be broken up into manageable
pieces.
The fundamental disconnect here is that some people seem to think that
style guidelines like "no lines over 80 columns" are goals, they
aren't, they are just heuristics that have been found to point out bad
coding practices.
Note: I'm not specifically arguing for keeping the 80-column rule, the
project I work on uses 100 columns, and that's quite workable, but I
haven't had any problem working with 80 columns as a limit either. I
do however think that just removing the limit without replacing it
with something better is a bad idea.
-Kevin Granade
> --
> Krzysztof Halasa
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
