[PATCH 2/5] UBI: fastmap: kill junk newlines and add a TODO about that

Richard Weinberger richard at nod.at
Wed Jun 6 17:30:11 EDT 2012


Am 05.06.2012 17:11, schrieb Artem Bityutskiy:
> +		/* TODO: nitpick, sorry for being annoying, but this should not
> +		 * be difficult to fix. I find it very irritating when there
> +		 * are useless blank lines like this - they only make less code
> +		 * fit my screen and make large functions even larger.
> +		 *
> +		 * Why we use blank lines inside a single function? To make
> +		 * code more readable. How we make it more readable? By
> +		 * separating logically different blocks of code with a
> +		 * newline.
> +		 *
> +		 * What is the perbose of these newlines before goto's? This is
> +		 * a single piece of error-handling code - you assing the
> +		 * return value and go to the further error processing. These
> +		 * newlines serve no purpose just blow the lines number in the
> +		 * code. Could we please kill them globally?
> +		 *
> +		 * I am again sorry - probably this is not completely
> +		 * technical, but I gave the explanation why these newlines are
> +		 * annying. And as a person who spent a lot of personal
> +		 * (non-paid) time maintaining this code and who will keep
> +		 * doing this - I think I have right to require to do such
> +		 * cosmetic things :-) If you do not agree with my reasoning,
> +		 * may be this is better - you'll keep me happier :-) */
>  		goto out;

Your and mine coding style are quite different. :-)
I *hate* it when statements like goto and return are glued to a code block.
E.g.

a = 1 + b;
res = c + a;

return res;

vs:

a = 1 + b;
res = c + a;
return res;

Anyway, I'll change this to match the UBI style.

Thanks,
//richard

P.s: Can we please have a ubi_checkpatch.pl? *SCNR*

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120606/b796df28/attachment.sig>


More information about the linux-mtd mailing list