5

In the early time, maybe just few line code, But I have see too many repeated and messy codes involve serialize/deserialize interference the main logic. So I try to persuade the team members to wrap a function for operations like read/write/update data ,example as:

 void updateCopyTimes(int times)
  { 
    player->getExtendJson["AcopyTimes"] = Json::Value(times);
    player->updateExtendJson();
  }

  int getCopyTimes()
  {
       const int copyTimes = player->getExtendJson["AcopyTimes"].asInt();
       return copyTimes;
  }

The point support my opinion is:

1) With a wrapper function, we can have a good code hierarchy, we can focus on the logic, make the serialize/deserialize clean, not spreading anywhere.

2) Easy to extend, we can easy to modify the program to serialize into a mysql field(int/string/date ...), into another mysql json field, easy to add checking code ,with the main logic immune to the modification.

The discommender argue that :

1) In our program , the chance to switch to another serialization format is pretty low, nearly imposible. It's not worthwhile to do it.

2) Wrapping such a function is over-thinking, if we do that, more code we have to write. And if we can finish the job, why bothering yourself ?

3)And most importantly, different developers hard to follow this rule.

So under what condition(operations type, code quantity ...), we need such a wrapper function ?

  • What if you decide AcopyTimes should be a double? – user253751 Apr 6 '17 at 5:21
  • To abstract the "complexity" of the 2 lines of code in a separate function updateCopyTimes already eradicates the possible error of updating the map without calling "updateExtendJson()". I'd absolutely go for this one. Plus, the calling code doesn't need to care about the internal representation of the data (map) any more. Plus: Should code be able to update/get these values if they do not have direct access to the player-object? – Stefan Woehrer Apr 6 '17 at 16:56
3

You would need to separate code out into a new function if it makes the code easier to read, reason about or maintain.

This is independent of the number of lines that you would move into the function, but for small sections of code it is a subjective judgement call which version is easier to read.

If you often have comment markers in the code like this

void function_a() {
  some code

  // serialization
  serialization code
  // end serialization

  more code
}

then that is an indication that it would be good to extract the code between the markers into a function of its own.

5

Your wrapper decouples serialization from application code. This just seems an unalloyed 'good' to me. See Dependency Inversion, Single Responsibility. I don't really understand why people resist basic software engineering practices.

  • The "basic software engineering practices." are not universal for all situations, and what is appropriate for embedded devices operating paint mixers might not be appropriate for huge enterprise monstrosities, and vice versa. – whatsisname Apr 5 '17 at 21:44
  • Highly embedded systems are an obvious exception, but I can think of few others. The OP doesn't appear to implementing such a system. – Nick Keighley Apr 6 '17 at 8:37
2

In addition to Bart's answer, I have found that wrapping such code in their own functions make it much easier to test and debug as you can easily write unit tests for each function and also see values of the input parameters and return values with breakpoints at the start and end of the function.

To answer your question, I will usually put code into its own function under the following conditions:

  • The code to be executed can be logically separated from other code and performs a single task
  • The code is reused in multiple locations
  • The logic required to perform a single task is complicated, but has clearly defined input parameters and output return values
  • There is potential for the logic to change in the future

In most cases, your opinion is in line with good software engineering practices. Although it is more work to write code in that way, it is better for future maintainability. This sort of mentality also separates mere programmers from good software engineers.

Your issue is more than just "when to put logic/code into its own wrapper function", but "how to guide your team members to adopt best practices for software engineering".

Many people who code tend to do things their own way, and I would say that it is really hard for you to change their mentality. Unfortunately, in most cases, customers just want to see the outcome and software engineers just want to get the job done and take the easy way out rather than to follow best practices.

When it comes to software changes, it looks more "impressive" from a non-engineer's perspective that a software engineer rushes and works day and night for 5 days to make a change rather than 5 hours because he or she has followed good software engineering principles.

By doing things the "right" way, you save time and effort now, rather than having to do additional work in the future. However, human nature, being what it is, tends to go for the reward now rather than the future in most situations. This is applicable for most aspects of life (think about eating now vs dieting, spending vs saving), not just software engineering.

This situation will likely not change because of human nature, and also, people are paid to get the job done, not to do it in the best way possible. However, you will have a better chance to be able to change this mentality once you are in a position to hire and fire, and you can pick and choose engineers who are able to get things done in the best way possible.

0

Extracting the serialization code, unless it is truly trivial, has the advantage that all your serialization code will be in one place, which usually makes it easier to spot stupid mistakes, or makes it easier to modify all serialization code in the same way (for example, add proper handling of null values to all your JSON serialisation code).

  • Thanks for your reply.The hard part is how to determine 'truly trivial', the developers treat it differently.Surely we can't go too far, but in a big code base I am working with, new developers tend to follow others way of writing code, if someone perviously made a wrong decision, then the error incline to continue. – wangdq Apr 6 '17 at 1:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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