Good codes are unrealistic?

[stereoMatching]

I am a newbie who just grduated.
I found my first job and begin to review some legacy codes

And I find out there are a lot of macros which could be replaced by function
Not even that, I almost could swear that the designer did not think carefully
before designed, the are a lot of weird interfaces,
what is the meaning to design something like

public :
  int getNum() const;
  void setNum(int const num);
 ................

protected :
  int num_;
.....................................

A lot of inline codes, even constructor and destructor
yes, there are nothing in the constructor and destructor, but there are a lot of "unseen" constructor and destructor
would be called implicitly, I could only hope that the compiler would be smart enough to reject all of the
unnecessary inline functions.

The worst thing maybe is "copy and paste"
Oh man, maybe this is one of the most cunning evil of programming

I believe there are other problems, and maybe it is worse than what I have covered up until now

I know our company is a small company
But I never imagine our legacy codes could be so **** poor
Are those beautiful codes only existed in those textbooks
which wrote by those masters?

The most important thing is, what should I do if there are a lot
of "copy and paste", weird interfaces(meaningless), more and more prone to error
macros?Because our codes are pretty fragile and a lot of bugs, prone
to crash. I just know that our company seldom or never review codes,
because we don't have times to do that. When bugs pop out and they failed
to find out the reason, they would just write some work around to cover it.

What would you try?ANy good ways or books?Since this is teamwork, I cannot
insist my opinion, but to follow the rules of the company.
I don't intent to leave this company in one or two years, except of producing
some ugly codes like that again, what could I do to make my life easier?

Thanks

ps : I can't change the legacy codes, because they don't want to see any bugs occur
yes, it is reasonable. No matter how poor the codes could be, it is very hard to
change it when it is widely spread within the whole product...
Now I only hope there would not be too many bugs hide in those legacy codes

[laserlight]

What would you try?

I would not try to rewrite from scratch
Things You Should Never Do, Part I by Joel Spolsky

The most important thing is, what should I do if there are a lot
of "copy and paste", weird interfaces(meaningless), more and more prone to error
macros?

Ensure that there is a high test coverage, then slowly refactor piece by piece.

what is the meaning to design something like

It might actually make sense, e.g., setNum enforces a range of allowed values. Hard to say without context.

[stereoMatching]

It might actually make sense, e.g., setNum enforces a range of allowed values. Hard to say without context.

int setNum(int const num)
{
  num_ = num;
}

void getNum() const
{
  return num;
}

It is very hard to change the legacy codes for now
And I don't want to produce any troubles or make
myself looks like a jerk in our team.
But it is possible to fix some redundancy codes
after I realize the architecture of the codes

Now I know why many magnificient codes are made
by small groups.Because there are only some programmers
like linux, stroustrup, andrei, meyers and other masters in this world.

[Martin O]

It is very hard to change the legacy codes for now
And I don't want to produce any troubles or make
myself looks like a jerk in our team.

That's an excellent idea. Accept the fact that you are a new programmer & are not always going to understand all the reasons for code to be written the way it is until you gain more experience. For example, it's very common to make all fields private & provide getters & setters to modify the field as in your example. Nothing wrong with that at all.

[laserlight]

int setNum(int const num)
{
  num_ = num;
}

void getNum() const
{
  return num;
}

You probably mixed up the return types, but anyway, that still does not show it is cruft because in the future, it may be the case that setNum will enforce some range of values, so designing to have such a setter and getter provides for this possibility.

[D_Drmmr]

what is the meaning to design something like

public :
  int getNum() const;
  void setNum(int const num);
 ................

protected :
  int num_;
.....................................

Could be useful if derived classes need to have a reference to the value.

A lot of inline codes, even constructor and destructor
yes, there are nothing in the constructor and destructor, but there are a lot of "unseen" constructor and destructor
would be called implicitly, I could only hope that the compiler would be smart enough to reject all of the
unnecessary inline functions.

Don't understand what you're trying to say here.

Are those beautiful codes only existed in those textbooks
which wrote by those masters?

In a sense, yes, because the code in textbooks doesn't have to hold itself up against evil users, or operating systems, or bugs in third party libraries. Often times, legacy code can contain many ugly things that have been put in over the years in order to solve all kinds of unexpected problems. If some code/design has proven itself in practice, you should try to comprehend it fully, before you even think about rewriting it or scrapping it and starting from scratch.

I just know that our company seldom or never review codes,
because we don't have times to do that. When bugs pop out and they failed
to find out the reason, they would just write some work around to cover it.

What would you try?ANy good ways or books?Since this is teamwork, I cannot
insist my opinion, but to follow the rules of the company.
I don't intent to leave this company in one or two years, except of producing
some ugly codes like that again, what could I do to make my life easier?

Keep an open mind and try to engage your colleagues into discussions about the best programming practices. If you see a lot of things that you think are wrong in the code, then you have a lot of concrete topics to talk about. Remember though, that as a beginner you don't have the experience that others have. You have not written and maintained complex programs that are used in practice in a team of programmers. So, there is plenty to learn, even from people who write ugly code.

[monarch_dodra]

It is very hard to change the legacy codes for now

Rule 1 about legacy code is you don't touch legacy code.

Even if it seems like the worst kind of code ever, it is also code that has been in production for a long time, and can be trusted, whereas your brand new code would first have to be thoroughly tested.

All the "evils" of which you speak are evil in terms of development, but once developed, it's all good.

Unless you are in for a grand re-factoring of the code, you won't gain much changing a macro here and there into a function... Except taking a risk of introducing a bug. (Note that I did not say you would, I said there is a risk).

Furthermore, there is nothing worse than "Mixed Pattern" programming. If the original programmer designed your app with Macros and char* strings, then try to use them, even though they are "not as good" as functions/templates and std::string.

I am a newbie who just grduated.
I found my first job and begin to review some legacy codes

Finally, legacy code is usually complicated, and, over time, has become riddled with "hacks", "patches" and fixes. Touching this kind of code without knowing the history of the code is usually a bad idea. This is even more true if you are a "newbie".

------

I know were you are coming from, but take it from someone who has been in the same situation: Styles change and languages evolve, but code that works will always work. Just move on to something else, something that actually requires your productivity.

[Lindley]

code that works will always work.

Never heard of "bit rot", huh?

In general I agree, but old code which is not in common use anymore has a surprising habit of having problems when you pull it out of mothballs again.

[monarch_dodra]

Never heard of "bit rot", huh?

In general I agree, but old code which is not in common use anymore has a surprising habit of having problems when you pull it out of mothballs again.

Well, I guess that's true, but that said, there is absolutely no reason to maintain/rewrite code that nobody is using anyways...

And if it doesn't work when you pull it out of mothballs, then yes, that's when you should start investigating.

[stereoMatching]

you should try to  comprehend it fully, before you even think about rewriting it or scrapping it and starting from scratch.

I would not try to rewritting something I don't understand
Except of some thing which easy to do
like make those unproper inline function become non-inline
or wrap those redundancy codes by template

And I forget to say another very importang thing
The codes lack well document and explanation
only a few lines of comments for classes and a few of functions

I know they are busy, but no matter how busy a programmer could be
Programmer should write comments, else the codes would become very hard to maintain

Programmer should write their program on a paper first before they try to implement it
except of some extremely easy cases.
It is very irresponsible to write codes without comments and verify your codes
on paper before you begin to write codes

Sometimes my comments of my codes are more than my source codes
The times I spend on writing comments are same or even more than develop source codes

Well document is very important when develop software
What if someday those programmers all leave?
Who could decipher those legacy codes?
Writing document may spend many of times, but it is worth to
Especially when you want to maintain your codes

[monarch_dodra]

While what you say is true, remember that programming is a business, and there is no money to be made from writing comments. You can ask your boss, the person that pays you what he thinks you should be doing with your time...

[laserlight]

there is no money to be made from writing comments.

Furthermore, comments may get out of sync with code, so where you have the choice, it is better to write descriptive code than to write descriptive comments.

EDIT:

Programmer should write their program on a paper first before they try to implement it
except of some extremely easy cases.
It is very irresponsible to write codes without comments and verify your codes
on paper before you begin to write codes

I might sketch out an algorithm on paper first, but writing a program on paper is reserved for exams in school (or maybe an interview). If you want to write something to "verify your codes" before you implement, write your tests first.

[stereoMatching]

Furthermore, comments may get out of sync with code, so where you have the choice, it is better to write descriptive code than to write descriptive comments.

The best comments is don't need any comments
But this is real world, even the lib which developed by those top programmers need to be well documented
look at boost, openCV, loki and so on

Yes, comments can't execute, but as the source codes become bigger and bigger
you will realize it is worth to. In the long run, good document could save you a lot
of times, and times mean money.

The sad thing is, this is real world. So I should not write any comments since our
company do not treat this seriously. Why should I behave a good discipline since
another treat it as bad habits and neccessary?Don't act different else you will
become a jerk, this is nothing related to "correct" or "wrong", just act like you
are with them if you don't want to have a hard life.

I might sketch out an algorithm on paper first, but writing a program on paper is reserved for exams in school (or maybe an interview).

I would think carefully before I define the architecture, function is better?lass is better? inherited or not?
what kind of the design pattern should be use and so on.
It is hard to believe one could make a good design before they think it carefully

Yes, it is impractical to think too many, but it is also impractical to "jump to the compiler"
Yap, it is fast, but it could produce fragile products either.
It is impractical to design a flawless software, but it is also impractical to design software
by the way of "jump to the compiler" and the philosophy of "get the code done ASAP"

ps : I just found two bugs yesterday, looks like it is hidden in our source codes long ago(maybe more than one year?),
cause by copy and paste(the function will always return false)

[laserlight]

But this is real world, even the lib which developed by those top programmers need to be well documented
look at boost, openCV, loki and so on

That is because there is no choice: programming interfaces must be documented in order to be used properly, and one way of doing that is to use special comments that a document generator parses to generate documentation. Consequently, it is not so much commenting the library code as documenting the library interface.

EDIT:
Also, since interfaces tend to change less than implementation, such documentation is less likely to go out of sync.

EDIT in response to your edit:

I would think carefully before I define the architecture, function is better?lass is better? inherited or not?
what kind of the design pattern should be use and so on.
It is hard to believe one could make a good design before they think it carefully

Certainly, but are you so sure that your colleagues did not think carefully, but were forced into making design trade-offs due to other constaints such as time? Furthermore, design is not necessarily all about a big design up front. This might be a short but good read: Design Is Not a Development Phase.

By the way, it would be better if you made new posts in reply instead of editing your own post continuously.

[stereoMatching]

That is because there is no choice: programming interfaces must be documented in order to be used properly

To tell you the truth, our company don't explain what are those interfaces are doing
Besides, comments need to be maintain too

dump the codes asap or design a perfect lib, neither extremes are practical
if our company really want to make a long run it should grasp the balance between them

well, time will proof everything, since I am not the boss, I would not argue with them
Just play a good employee, follow the rules and get along with the teammates