Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] RFD: Creating subdirectories in epan/dissectors/

From: Evan Huus <eapache@xxxxxxxxx>
Date: Thu, 30 Aug 2012 21:38:48 -0400
On Thu, Aug 30, 2012 at 8:29 PM, Ed Beroset <beroset@xxxxxxxxxxxxxx> wrote:
> Evan Huus wrote:
>>
>> On Thu, Aug 30, 2012 at 1:46 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
>> wrote:
>
>
>>> Unwieldy how?  Except for having to know not to do "vi
>>> epan/dissectors/<tab><tab>" (for fear of too many pages of output) I
>>> don't
>>> find the directory unwieldy.
>>
>>
>> That's part of it - I still do that accidentally on occasion. The
>> other part of it is just that the number of files is overwhelming.
>> It's not necessarily inefficient for the computer, but it is certainly
>> inefficient for a mental model of the source structure, and it feels
>> daunting, which is something we want to avoid in order to encourage
>> new developers. I know when I checked out the source tree for the very
>> first time I looked at the size of it and had very much a "where do I
>> start?!" moment.
>
>
> I'm relatively new to Wireshark development (only a few years), so I
> remember that moment too.  However, I'm not sure that organizing things into
> subdirectories would really help that much.  What you've identified though,
> is a real thing that might be addressed, which is that regardless of how the
> files are physically organized, it would be useful to structure things to
> aid human beings who look at and work with the source files.  Doxygen, which
> is already lightly supported, could help there without a lot of additional
> effort.  I think that might be a better way to approach this problem than
> rearranging the source code directory structure.  What do you think?

It might not help a lot, but it will help a little. Doxygen is a good
tool which we should probably be using more - perhaps that should be
its own thread? - but its use doesn't exclude trying to find a logical
way to structure the source. Also, I would hardly call this a
rearrangement. All we're trying to do is make some existing structure
a bit more explicit.