I'd recommend to check stack/prog/ram usage for this change, and compare before/after. I understand your point about readability, you know how often I focus on this, but:
- this readability occurs within an internal procedure (not exposed to users). - you'll get better readability within this procedure as POSTINC will fade way behind your pseudo-var, but your pseudo-var now inherits from this readability (you're moving the readability problem one step away - in any case you'll put a comment about POSTINC explaining what it does, so in the end, avoiding a pseudo-var for this + put a comment will bring the level of readability. Do you see what I mean ? Do I understand well when I say this pseudo-var would just be a getter or setter for POSTINC ? Why not using an alias instead, with a more human understable meaning ? Thinking about this, I would not recommend this too as it would hide the very specific usage/meaning of POSTINC behind a user variable (it would look like any other variable but would really be special as it acts on FSR). Cheers, Seb 2011/4/3 mattschinkel <[email protected]> > > But what would be the benefits ? > > readability, and standardization. Maybe we'll be running USB on > another type of processor some day. > > Matt. > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > > -- Sébastien Lelong http://www.sirloon.net http://sirbot.org -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
