Okay, I understand better where you're coming from. For an internal representation, that's fine.

However, don't expect users to work in that same system for input and output: in my experience, people thinking in terms of DMS will usually be thinking in terms of London's longitude as -0°7′39″ = -(0°7′39″), not as = (-1°) + 52′ + 21″. If your program outputted -1 52 21, someone looking at a map of England would be forgiven for assuming you were printing the longitude of (... /me searches a map for an example location...) slightly west of Swindon, not the longitude of London -- and if I entered -1 52 21, I would expect your program to interpret that as being near Swindon, not London.

For internals, I'm now in agreement with AnomalousMonk's post, where it was recommended to do everything internally as arc-seconds. I now like a that a lot more than doing everything in decimal degrees: the fractions 1/60 and 1/3600 don't get represented well in internal binary floating-point notation, whereas -459 arc-seconds is stored quite simply as an integer; this also makes the internal angle representation more like the time representation (seconds since the epoch); I also think that would make all the internal math much simpler.