Hello,
I have a diffictly deciding where exactly to split a long line of code. for example, this line of code is too long
uCTSTime = bb_get_frame_time(pDevice->preamble_type, byPktType, 14, pDevice->byTopCCKBasicRate);
if i spit it this way:
uCTSTime =
bb_get_frame_time(pDevice->preamble_type, byPktType, 14, pDevice->byTopCCKBasicRate);
It does not help as the second line is still too long. I considered doing it this way instead:
uCTSTime = bb_get_frame_time(pDevice->preamble_type, byPktType, 14,
pDevice->byTopCCKBasicRate);
But i did this on one of my patches and i was told it is not advisable to split a line between
parenthesis '(' and ')'
how can i go about this please?
On Thu, Oct 20, 2022 at 12:27 PM Bhaskar Chowdhury
<[email protected]> wrote:
>
> Use forward slash at the end every single chunk or piece of that line.
>
> Example :
>
> Veryyyyyyylooooooong. Linerrrrrrrrrrrrrrr
>
> Veryyyyyyyyyyyyy /
>
> Looooonggggggggg /
>
>
> Linerrrrrrrrrrr /
>
Thanks
>
> On Thu, 20 Oct 2022 at 16:43, Ubuntu <[email protected]> wrote:
>>
>> Hello,
>> I have a diffictly deciding where exactly to split a long line of code. for example, this line of code is too long
>>
>> uCTSTime = bb_get_frame_time(pDevice->preamble_type, byPktType, 14, pDevice->byTopCCKBasicRate);
>>
>> if i spit it this way:
>> uCTSTime =
>> bb_get_frame_time(pDevice->preamble_type, byPktType, 14, pDevice->byTopCCKBasicRate);
>>
>> It does not help as the second line is still too long. I considered doing it this way instead:
>> uCTSTime = bb_get_frame_time(pDevice->preamble_type, byPktType, 14,
>> pDevice->byTopCCKBasicRate);
>> But i did this on one of my patches and i was told it is not advisable to split a line between
>> parenthesis '(' and ')'
>>
>> how can i go about this please?
>
> --
>
>
> Bhaskar Chowdhury
> about.me/unixbhaskar
On Thu, Oct 20, 2022 at 12:34:02PM +0100, Tanju Brunostar wrote:
> On Thu, Oct 20, 2022 at 12:27 PM Bhaskar Chowdhury
> <[email protected]> wrote:
> >
> > Use forward slash at the end every single chunk or piece of that line.
> >
> > Example :
> >
> > Veryyyyyyylooooooong. Linerrrrrrrrrrrrrrr
> >
> > Veryyyyyyyyyyyyy /
> >
> > Looooonggggggggg /
> >
> >
> > Linerrrrrrrrrrr /
No, please do not do that in normal C code. That's only for rare cases,
like in a #define, that this style would be needed.
thanks,
greg k-h
Tanju, some additional hints. First of all, please don't send cleanup
patches to address checkpatch --file complaints about overly long
lines. It's generally not worth the code churn.
Secondly for code that *you* are writing, think about why you have
lines which are exceeding the line width in the first place. Is it
because code is being nested too deeply, and perhaps some judicious
function refactoring with good function names might make the code
clearer? Would adding some temporary variables that are judiciously
named make the code look clearer?
The rules about "thou shalt never have lines which exceed 78
characters" are rules of thumb. The high level goal is to make the
code more readable and easier to understand, since good code is
maintainable code. And sometimes it's not just about where to split
lines of code but whether there is a better way to structure the code
so that long lines aren't needed in the first place.
Cheers,
- Ted
On 10:39 Thu 20 Oct 2022, Theodore Ts'o wrote:
>Tanju, some additional hints. First of all, please don't send cleanup
>patches to address checkpatch --file complaints about overly long
>lines. It's generally not worth the code churn.
>
>Secondly for code that *you* are writing, think about why you have
>lines which are exceeding the line width in the first place. Is it
>because code is being nested too deeply, and perhaps some judicious
>function refactoring with good function names might make the code
>clearer? Would adding some temporary variables that are judiciously
>named make the code look clearer?
>
>The rules about "thou shalt never have lines which exceed 78
>characters" are rules of thumb. The high level goal is to make the
>code more readable and easier to understand, since good code is
>maintainable code. And sometimes it's not just about where to split
>lines of code but whether there is a better way to structure the code
>so that long lines aren't needed in the first place.
>
>Cheers,
>
> - Ted
Righto!! I failed to miss it my replies. That an editor can be trained or
customized to that way. Especially , vim and emacs.
--
Thanks,
Bhaskar
"Here's looking at you kid"-- Casablanca
https://about.me/unixbhaskar
On Fri, Oct 21, 2022 at 12:38 AM Bhaskar Chowdhury
<[email protected]> wrote:
>
> On 10:39 Thu 20 Oct 2022, Theodore Ts'o wrote:
> >Tanju, some additional hints. First of all, please don't send cleanup
> >patches to address checkpatch --file complaints about overly long
> >lines. It's generally not worth the code churn.
> >
> >Secondly for code that *you* are writing, think about why you have
> >lines which are exceeding the line width in the first place. Is it
> >because code is being nested too deeply, and perhaps some judicious
> >function refactoring with good function names might make the code
> >clearer? Would adding some temporary variables that are judiciously
> >named make the code look clearer?
> >
> >The rules about "thou shalt never have lines which exceed 78
> >characters" are rules of thumb. The high level goal is to make the
> >code more readable and easier to understand, since good code is
> >maintainable code. And sometimes it's not just about where to split
> >lines of code but whether there is a better way to structure the code
> >so that long lines aren't needed in the first place.
> >
> >Cheers,
> >
> > - Ted
> Righto!! I failed to miss it my replies. That an editor can be trained or
> customized to that way. Especially , vim and emacs.
> --
> Thanks,
> Bhaskar
>
> "Here's looking at you kid"-- Casablanca
> https://about.me/unixbhaskar
I appreciate all your replies. They have been quite helpful. I will
try to apply them as I continue on my journey of contributing to the
kernel