Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

struct ID3_3_EXTENDED_HEADER{
    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 :

struct ID3_4_EXTENDED_HEADER{
    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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.