ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Coding style and example dissector

From: Michael Lum <michael.lum@xxxxxxxxxxxxxxxxx>
Date: Wed, 18 Dec 2013 10:09:41 -0800
Thanks for replying guys.

I am adding the modelines now.
I happen to use Vim and those are exactly the settings that I was using.

I get snapshots of the changes in Wireshark because I only look at the code
when I want to add something.  Sometimes this can be years.  Sometimes I see
the code change one way and then back again.

When I go to merge my changes against the trunk it takes more time than I
expect because of some of these changes.  

There have been a few times were I just don't bother to send in a patch.
But on the other hand maybe that's not bad over 10 years.

Bill, I understand, I do the same things in my code.
(I guess its when someone goes and changes it 'another' way.)
(Bill it wasn't necessarily you, this has been a frustration for years.)

Okay, I'll live with it.
You guys have a tough job and Wireshark is worth it.

Have a Merry Christmas and Happy New Year


Michael Lum (michael.lum@xxxxxxxxxxxxxxxxx) | STAR SOLUTIONS | Principal Software Engineer
4600 Jacombs Road, Richmond BC, Canada V6V 3B1 | +1.604.303.2315
 

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Bill Meier
> Sent: December 18, 2013 9:29 AM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Coding style and example dissector
> 
> On 12/18/2013 7:52 AM, Joerg Mayer wrote:
> > On Tue, Dec 17, 2013 at 05:55:30PM -0800, Michael Lum wrote:
> >> Could someone please write a coding style section for the new 
> >> dissectors and perhaps point to the best example dissector.
> >
> > doc/README.developer last sections (5. White space 
> convention) more or 
> > less is what we have.
> >
> >> Currently, many of the dissectors I have submitted are having 
> >> arbitrary white space/style changes made.
> >>
> >> I completely understand changes, for bugs, API changes, 
> and warnings 
> >> missed because of cross-platform builds.
> >>
> >> But I don't understand the need to change FROM a 
> consistent style to some other style.
> >
> > Maybe the consistent form was not apparent to the person 
> make these changes.
> > Adding a mode-line seems like a good way to prevent this 
> sort of "arbitrary"
> > changes.
> >
> > If you are the de facto "maintainer" of these dissectors 
> and you don't 
> > feel comfortable with these changes then maybe open a bug 
> and ask for 
> > these changes to be reverted - you have to feel comfortable 
> with your code.
> > In case you can live with (more or less) any coding style 
> as seems to 
> > be the case for you then it's "only" time someone else might have 
> > spent doing other things but no harm was done and no revert 
> is necessary.
> >
> > Ciao
> >        Jörg
> >
> 
> Michael:
> 
> You are probably referring to various changes I've made.
> 
> As I make updates in dissectors, I've gotten in the habit of 
> doing a once-over and making changes related, to a large 
> extent, to whitespace (field alignment, consistent 
> indentation, trailing whitespace, etc) but which can/do shade 
> over into changes in style.
> 
> Looking back, (and based upon some other recent comments) I 
> think I need to "slow down" a bit.
> 
> I'm happy to revert changes upon request.
> 
> Bill
> 
> 
> ______________________________________________________________
> _____________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe