Skip to main content
edited body
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143
  1. Given the number (and length) of arguments you're passing, I'd prefer to see the arguments passed one per line as I've formatted them above, rather than a variable number per line to justify out to some particular right margin.

  2. Since stringify_state isn't intended to modify the stateState whose address is being passed, it's probably better to define the parameter as a State const *. Likewise with the local variables, so the first lines would probably be better written something like this:

     char* stringify_state(State const* state) {
         Pet const* p = state->pet;
         Settings const* s = state->settings;        
    
  1. Given the number (and length) of arguments you're passing, I'd prefer to see the arguments passed one per line as I've formatted them above, rather than a variable number per line to justify out to some particular right margin.

  2. Since stringify_state isn't intended to modify the state whose address is being passed, it's probably better to define the parameter as a State const *. Likewise with the local variables, so the first lines would probably be better written something like this:

     char* stringify_state(State const* state) {
         Pet const* p = state->pet;
         Settings const* s = state->settings;        
    
  1. Given the number (and length) of arguments you're passing, I'd prefer to see the arguments passed one per line as I've formatted them above, rather than a variable number per line to justify out to some particular right margin.

  2. Since stringify_state isn't intended to modify the State whose address is being passed, it's probably better to define the parameter as a State const *. Likewise with the local variables, so the first lines would probably be better written something like this:

     char* stringify_state(State const* state) {
         Pet const* p = state->pet;
         Settings const* s = state->settings;        
    
deleted 9 characters in body
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143

It may just be a pet peeve of mine, but I think this divides into a cleaner set of layers of abstraction. With your original code, we have a single function that mixes a fairly high level of abstraction (format a State into a string) with lower levels of abstraction (e.g., memory management).

It may just be a pet peeve of mine, but I think this divides into a cleaner set of layers of abstraction. With your original code, we have a single function that mixes a fairly high level of abstraction (format a State into a string) with lower levels of abstraction (e.g., memory management).

It may just be a pet peeve of mine, but I think this divides into cleaner layers of abstraction. With your original code, we have a single function that mixes a fairly high level of abstraction (format a State into a string) with lower levels of abstraction (e.g., memory management).

deleted 17 characters in body
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143

#Levels of abstraction

It may just be a pet peeve of mine, but I think this divides into a cleaner set of layers of abstraction. With your original code, we have a single function that mixes a fairly high level of abstraction (format a State into a string) with lower levels of abstraction (e.g., memory management).

@vnp's code sort of inverts the layers of abstraction, so we have the higher level of abstraction at the bottom, and the lower level of abstraction above it.

This one gets the layers of abstraction closer to how I'd like to see them: the memory management and general purpose stringifying is at the bottom of the stack, and the more specific higher level concern of Stringifying a State is at an upper layer. So, something like a call graph accurately reflects the levels of abstraction being dealt with in the code.

#Other Points

#Other Points

#Levels of abstraction

It may just be a pet peeve of mine, but I think this divides into a cleaner set of layers of abstraction. With your original code, we have a single function that mixes a fairly high level of abstraction (format a State into a string) with lower levels of abstraction (e.g., memory management).

@vnp's code sort of inverts the layers of abstraction, so we have the higher level of abstraction at the bottom, and the lower level of abstraction above it.

This one gets the layers of abstraction closer to how I'd like to see them: the memory management and general purpose stringifying is at the bottom of the stack, and the more specific higher level concern of Stringifying a State is at an upper layer. So, something like a call graph accurately reflects the levels of abstraction being dealt with in the code.

#Other Points

deleted 17 characters in body
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143
Loading
added 1090 characters in body
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143
Loading
added 1090 characters in body
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143
Loading
Source Link
Jerry Coffin
  • 33.6k
  • 4
  • 75
  • 143
Loading