public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: michael <trimarchi@gandalf.sssup.it>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] USB style patch
Date: Wed, 26 Nov 2008 12:23:24 +0100	[thread overview]
Message-ID: <492D31AC.2070006@gandalf.sssup.it> (raw)
In-Reply-To: <3efb10970811260315y72417986uf4348dbb3cbd3028@mail.gmail.com>

Hi,

Remy Bohmer wrote:
> Hello Michael,
>
> Nice work, but I have a few small comments:
>
>   
>> +                       case USB_PROT_HID_MOUSE:
>> +                               printf("Mouse");
>> +                               break;
>> +                       default:
>> +                               printf("reserved");
>>                        }
>>                        break;
>>     
>
>   
I check it.
> A default case without a break...
>
>   
>> +               case US_SC_SCSI:
>> +                       printf("Transp. SCSI");
>>                        break;
>>                default:
>> -                       printf("%s",usb_get_class_desc(dclass));
>> +                       printf("reserved");
>> +                       break;
>>     
>
> And a default case with a break...
> I see the 'break' keyword is not being used very consequent across all
> these files/switch-statements.
>
>   
I check
>> -               printf("  NOTE: this command is obsolete and will be phased out\n");
>> -               printf("  please use 'usb storage' for USB storage devices information\n\n");
>> +               printf("  NOTE: this command is obsolete and will be"
>> +                       " phased out\n");
>> +               printf("  please use 'usb storage' for USB storage devices"
>> +                       " information\n\n");
>>     
>
> I believe it is good to keep line lengths below 80 characters in
> general, but code should not become less readable by this.
> In case of printf lines, it becomes more difficult to 'grep' for the
> strings printed in the terminal to find them back in the code.
> So, I am very curious about the point of view Wolfgang about this
> rule. (How strict does this rule need to be applied?)
>   
I prefer to break the line but I wait for Walfgang answer.
> Kind Regards,
>
> Remy
>
>   
Regards Michael

  reply	other threads:[~2008-11-26 11:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-26 10:45 [U-Boot] [RFC PATCH] USB style patch Michael Trimarchi
2008-11-26 11:15 ` Remy Bohmer
2008-11-26 11:23   ` michael [this message]
2008-11-26 12:07     ` Wolfgang Denk
2008-11-26 13:18       ` michael
2008-11-26 15:14         ` Wolfgang Denk
2008-11-26 16:24         ` [U-Boot] grep for message (was: USB style patch) Alessandro Rubini
2008-11-27 11:21           ` [U-Boot] grep for message michael

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=492D31AC.2070006@gandalf.sssup.it \
    --to=trimarchi@gandalf.sssup.it \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox