Representative comment



  • /* Font names are stored as null-terminated UTF-16 Pascal strings. */



  • Wow, I think I can count at least four things wrong with that one comment. Now, I guess that that comment is in the middle of a global data header file, as opposed to being in the planning documentation?



  • @drachenstern said:

    Wow, I think I can count at least four things wrong with that one comment. Now, I guess that that comment is in the middle of a global data header file, as opposed to being in the planning documentation?

    Would be nice if it was, but no, the header comment on that field is the entirely non-helpful

    pg_char	 	name[FONT_SIZE + BOM_HEADER];		/* "Name" of font */

    The comment I posted was found in the middle of a code file, explaining why the font name was being accessed as &font->name[1] rather than font->name.



  • @Carnildo said:

    /* Font names are stored as null-terminated UTF-16 Pascal strings. */
     

    So what's your problem?  I'd die for comments like that!  It's a Pascal string -- that means it has a leading length count, probably 2 bytes long (pg_char type in your example).  Then the data also has a null terminator, probably actually two nulls.  This makes it more easily usable from a C context.  Then it tells you that it's in UTF-16 encoding.

    I repeat, so what's your problem?



  •  Why bother null terminating it if you've got a length count?



  •  @vt_mruhlin said:

     Why bother null terminating it if you've got a length count?

    Didn't Joel Sposky call those Fucked Strings once?

    They'll get out of sync if the string is at all mutable.



  • @vt_mruhlin said:

     Why bother null terminating it if you've got a length count?

     

    Because you can simply pass them to WinAPI.



  • @UpNDown said:

    So what's your problem?  I'd die for comments like that!  It's a Pascal string -- that means it has a leading length count, probably 2 bytes long (pg_char type in your example).  Then the data also has a null terminator, probably actually two nulls.  This makes it more easily usable from a C context.  Then it tells you that it's in UTF-16 encoding.

    I repeat, so what's your problem?

    That we still don't know whether it's UTF-16BE or UTF-16LE!

    Duhhhhhhhh



  • @Carnildo said:

    /* Font names are stored as BSTR:s. */



    There, FTFY.


Log in to reply