Take the 2-minute tour ×

I really hope you can give me some interesting viewpoints for my situation, because I am not satisfied with my current approach.

I am writing an MP3 parser, starting with an ID3v2 parser.

Right now I`m working on the extended header parsing, my issue is that the optional header is defined differently in version 2.3 and 2.4 of the tag.

The 2.3 version optional header is defined as follows:

    DWORD dwExtHeaderSize;          //Extended header size (either 6 or 8 bytes , excluded)
    WORD  wExtFlags;                //Extended header flags
    DWORD dwSizeOfPadding;          //Size of padding (size of the tag excluding the frames and headers)

While the 2.4 version is defined :

    DWORD dwExtHeaderSize;          //Extended header size (synchsafe int)
    BYTE  bNumberOfFlagBytes;       //Number of flag bytes
    BYTE  bFlags;                   //Flags

How could I parse the header while minimizing code duplication?

Using two different functions to parse each version sounds less great, using a single function with a different flow for each occasion is similar, any good practices for this kind of issues ? Any tips for avoiding code duplication?

Any help would be appreciated.

share|improve this question

1 Answer 1

You're worrying about code duplication for 2 headers of 3 fields? In the time it took you to write this question, you could have coded both parsers. Honestly, just get it done.

If I'm way off base here, please update your question to indicate why duplication at such a small scale is a concern for you.

If you really don't want two separate functions, then code a single one with an if check in there.

I could see writing a common routine to break out the flags within the Word | Byte.

It doesn't appear that the logic surrounding the header size field is significant enough to justify worrying about duplication, but if it were non-trivial then another common routine for validation could make sense.

I don't mean to be harsh but the "good practice" in this case is to get it done and to move on to the bigger design issues of your problem space. I would call this concern a case of premature optimization. Part of the reason why you're struggling to find the "right answer" is because the difference between "right" and "good enough" is pretty small.

share|improve this answer

Your Answer


