Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Now that I know some of the basics of C++, I must admit that I still find it very hard to deal with code that others have written in C++. This may inherently be so, as C++ allows for complex object hierarchies that are, or at least to me, very hard to grasp if one is just supplied with a C++ Project without any further comments or instructions.
So my question is more a question to the more experienced C++ programmers among you: how can someone understand a large C++ project written by others?
I easily loose my way and can be lost for weeks, if I try to understand how a large project of, for example, 10,000 lines of code is written. Functions of classes are pointers to functions of different classes that may or may not be overloaded and may or may not be inherited by other classes, etcetera, without ending.
Are there any practical tips that may speed up my ability to read and understand large C++ projects? Is there perhaps a tutorial with such tips? Please, elaborate! :)
I've been programming professionally for some time now, and as such I have repeatedly been handed down codebases written by others before me. Understanding is never easy, especially when the code is inconsistent.
The first thing to realize, though, is that learning your ways in a new codebase is not so different than re-discovering a codebase you had not touched for a while. Thus, whether written by your old-self of others does not matter much; and since you probably manage to cope with re-discovering codebases you had worked on before, you should be able to discover new codebases as well. Don't lose hope.
The second thing to realize is that understanding is a vague term, and there are certainly different degrees. Often times, nobody asks you to understand the ins and outs completely; more likely you will be asked to understand a portion of the codebase in which either there is a bug or some new functionality should be developed. Therefore, as time passes, you will gradually gain an understanding of various portions, and you will inevitably have a deeper knowledge of the portions you worked the most whilst others can be relatively abstract or even completely obscure. It's okay, it's been a long time since human beings stopped trying to learn everything there was to learn.
With that said, there are several axis of understanding you can try:
you should look for architecture: a good thing is to trace the library dependencies (the Makefile/Project should help here) this will give you the coarse technical blocks out of which the application is built. Executables are normally leaves of the dependency trees.
you should look for data-flow: what's the trigger of the application (called directly or as a callback) ? what are the steps followed by this data (roughly, just a sketch). Do not hesitate to focus on a specific narrow usecase and use the debugger to trace things, and do not try to dig too deep at first; just get a feel of things.
There are also other axis that may help gaining some understanding of the domain the application has been written for. An understanding of the domain is useful because it provides you with a key insight on what should happen and it also helps you decipher the comments/function names.
user documentation: what is this used for ? if you can arrange for a demo it is generally very helpful, otherwise maybe you can try playing with it yourself (in a test environment)
tests: what is tested ? what is exposed to the user ?
persistent data: what is serialized ? what is saved in a database ? Persistent data is accessed at some point, so it helps if you understand when it is read/written.
If it is a working product (that runs) and you can "debug" it, start by looking at just one particular feature.
Learn how it is working from the user's point of view (UI, behaviour, inputs, outputs, ...).
Once you know the feature from the outside, just look for the code for that feature (only that feature); the starting point might be a handler for a menu, or from a dialog or a mouse/pointer event.
From there; manually trace the code for one action or sub-feature; skip deep internal libraries (treat them as black box for now) and learn how it works.
Once you know that section of code, dig deeper in libraries API that was called from the upper level code.
Take your time.
Do not try to understand everything at once.
Draw up schematic (pen and paper) of the dependencies (stay high level, no class dependencies at the beginning).
Good luck.
The problem that you are mentioning does not have clear and simple answer. Nevertheless here are some tips:
At the beginning try to randomly remember everything. Names of directories, classes, params of templates, etc. As much as you can. This sounds pointless but still makes sense.
While working with the code always think "Have I looked at this function/param/etc before?" If the answer is yes, spend with this piece of code more. If not, just make basic grasp and go on.
As the time will go on, you will find out that more and more sounds clear and easier to grasp.
It is impossible to give any exact values because size and complexity of projects vary greatly. Do not expect simple and immediate results.
Other points:
You definitely need a source code browser. Spend time in learning how to use it. Good example is http://sourceinsight.com/. This is not my site!!! I do have my own site. I will not mention it here.
If you see a function that is called 500 times, it is 500 times more likely that knowledge about this function will be useful comparing with a function, that is called only once.
The best is to grasp the architecture of the project. Trying to do this it is necessary to remember that project may have no architecture at all.
Studying the code you should remember your task. Typical situation - you need to modify something or fix a bug. If this is so look for the right part of the code and focus your effort on it.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The question of understanding a large code has previously been well answered. But I feel I should ask this question again to ask the problems I have been facing.
I have just started a student job. I am a beginner programmer and just learned about classes two months back. At the job though, I have been handed a code that is part of a big software. I understand what that code is supposed to do (to read a file). But after spending a few weeks trying to understand the code and modify it to achieve our desired results, I have come to the conclusion that I need to understand each line of that code. The code is about 1300 lines.
Now when i start reading the code, I find that, for example, a variable is defined as:
VarType VarName
Now VarType is not a type like int or float. It is a user defined type so i have to go the class to see what this type is.
In the next line, I see a function being called, like points.interpolate(x);
Now i have to go into another class and see what the interpolate function does.
This happens a lot which means even if I try to understand a small part of the code, I have to go to 3 or 4 different classes and keep them in mind all at one time without losing the main objective and that is tough.
I may not be a skilled programmer but I want to be able to do this. Can I have some suggestions how i should approach this?
Also (I will sound really stupid when I ask this) what is a debugger? I hope this gives you an idea of where I stand (and the need to ask this question again). :(
With any luck, those functions and classes should have at least some documentation to describe what they do. You do not need to do know how they work to understand what they do. When you see the use of interpolate, don't start looking at how it works, otherwise you end up in a deep depth-first-search through the code base. Instead, read its documentation, and that should tell you everything you need to know to understand the code that uses it.
If there is no documentation, I feel for you. I can suggest two tips:
Make general assumptions about what a function or class will do from its name, return type and arguments and the surrounding code that uses it until something happens that contradicts those assumptions. I can make a pretty good guess about what interpolate does without reading how it works. This only works when the names of the functions or classes are sufficiently self-documenting.
If you need a deep understanding of how some code works, start from the bottom and work upwards. Doing this means that you won't end up having to remember where you were in some high level code as you search through the code base. Get a good understanding of the low level fundamental classes before you attempt to understand the high level application of those types.
This also means that you will understand the functions and classes in a generic sense, rather than in the context of the code that led you to them. When you find points.interpolate(x), instead of wondering what interpolate does to these specific points with this specific x argument, find out what it does in general. Later, you will be able to apply your new-found knowledge to any code that uses the same function.
Nonetheless, I wouldn't worry about 1300 lines of code. That's basically a small project. It's only larger than examples and college assignments. If you take these tips into account, that amount of code should be easily manageable.
A debugger is a program that helps you debug your code. Common features of debuggers allow you to step through your code line-by-line and watch as the values of variables change. You can also set up breakpoints in your code that are of interest and the debugger will let you know when it's hit them. Some debuggers even let you change code while executing. There are many different debuggers that all have different sets of features.
Try making assumptions about what the code does based on its title. For example, assume that the interpolate function correctly interpolates your point; only go digging in that bit of code if the output looks suspicious.
First, consider getting an editor/IDE that has the following features:
parens/brackets/braces matching
collapsing/uncollapsing of blocks of code between curly braces
type highlighting (in tooltips)
macro expansion (in tooltips or in a separate window/panel)
function prototype expansion (in tooltips or in a separate window/panel)
quick navigation to types, functions and classes and back
opening the same file in multiple windows/panels at different positions
search for all mentions/uses of a specific type, variable, function or class and presentation of that as a list
call tree/graph construction/navigation
regex search in addition to simple search
bookmarks?
Source Insight is one of such tools. There must be others.
Second, consider annotating the code as you go through it. While doing this, note (write down) the following:
invariants (what's always true or must always be true)
assumptions (what may not be true, e.g. missing checks/validations or unwarranted expectations), think "what if"
objectives (the what) of a piece of code
peculiarities/details of implementation (the how; e.g. whether exceptions are thrown and which, which error codes are returned and when)
a simplified call tree/graph to see the code flow
do the same for data flow
Draw diagrams (in ASCII or on paper/board); I sometimes photograph my papers or the board. Specifically, draw block diagrams and state machines.
Work with code at different levels of abstraction/detail. Zoom in to see the details, zoom out to see the structure. Collapse/uncollapse blocks of code and branches of the call tree/graph.
Also, have a checklist of what you are going to do. Check the items you've done. Add more as necessary. Assign priorities to work items, if it's appropriate.
A debugger is a program that lets you execute your program step by step and examine its state (variables). It also lets you modify the state and that may be useful at times too.
You may use a debugger to understand your code if you're not very well familiar with it or with the programming language.
Another thing that may come in handy is writing tests or input data test sets for your program. They may reveal problems and limitations in terms of logic and performance.
Also, don't neglect documentation and people! If there's something or someone that can give you more information about the project/code, use that something or someone. Ask for advice.
I know this sounds like a lot, but you'll end up doing some of this at some point anyway. Just wait for a big enough project. :)
You may basically needs to understand what is the functionality of a function being called at first, then understand what is input and output to that function, for example, if you really needs to understand how interpolate is done, you can then go to the details. Usually, the name of the functions are self-explainable, you can get a feeling about what the function does from its name if the code is well written.
Another thing you may want to try is to run some toy examples to go through the code, you can use some of the debuggers or IDE that can help you navigate through the code. Understanding large-scale code takes time and experience, just be patience.
"Try the Debugger Approach"
[Update : A debugger is a special program that lets you pause a running program to examine the state of program (Variable Values/Which function is running/Who is the parent function etc.,)]
The way I do it is by Step Debugging the code, for the usecase I want to understand.
If you are using an Advanced/Mordern IDE then setting breakpoints at the entry point (like main() or a point of interest) is fairly easy. And from there on just enter into the function you want to examine or overstep the function.
To give you a step by step approach
Setup a break point in the main() methods (entry points) starting expression.
Run the program with debugging active
The program will break at the break point.
Now, if step over until you come across a function/expression that seems interesting. (say, your points.interpolate(x); ) function
Step into the function, and examine the program state like the variables and function stack, in live.
Avoid complex system Libraries. Just Step over/Step out. (Example: Avoid something like MathLib.boringComputaion() )
Repeat until the program exits.
I found out that this way of learning is very rapid and gives you a quick understanding of any complex/large piece of software.
Use Eclipse, or if you cant then try GDB if its C/C++. Every popular programming language has a decent Debugger.
Understand the basic debugging operations like will be a benifit:
Setting-up a breakpoint.
Stopping at a breakpoint.
Examine/Watch Variables.
Examine Function Stack (the hierarchy of function calls)
Single-Step - Stepping to next Line in Code.
Step-Into a function.
Step-Out of a function.
Step-over a function.
Jumping to the next breakpoint (point of interest).
Hope, it helps!
Many great answer have already been given. I thought to add my understanding as a former student (not too long ago) and what I learned to help me understand code. This particularly helped me because I began a project to convert a database I wrote in Java many years ago to c++.
1. **Code Reading** - Do not underestimate this important task. The ability to write code
does not always translate into the ability to read it -- and reading it can be more
frustrating than writing it.
Take your time and carefully discover what each line of the codes does. This will certainly help you avoid making assumptions unless you come across code that you are familiar with and can gloss over it.
2. Don't hesitate to follow references, locate declarations, and uncover definitions of
code elements you are reading. What you learn about how a particular variable,
method call, or class are defined all contribute to learning and ultimately to you
being able to perform your task.
This is particularly important because detective, and effective detective work, are essential parts of being bale to understand the small parts of the code so that you can, in the future, grasp the larger parts with less difficulty.
Others have already posted information about what a debugger is and you will find it is an invaluable asset at tracking down code errors and, I think, helps with code reading, knowledge gain, and understanding so you can be a successful programmer.
Here is a link to a debugger tutorial utilizing Visual Studio and may give you a strong understanding of at least the process at hand.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I've started a rather large 2D game engine project a few months ago, and I began noticing:
The code from the first one or two months is quite different to the more recent one:
The naming of variables feels a bit different
Some code style aspects are different
I'm sometimes wondering why I named some function that way, and can easily think of a better name
The code feels rather messy
There are parts where almost instantly a better way of doing it comes to my mind
The code seems as if its quality was significantly lower
However, at the time I wrote it, I was watching out to do everything right the same way as I do now.
Now, for my questions:
Is this a common situation, even in large commercial-style projects?
Should I consider investing (a lot of) time in refactoring and maybe even rewriting the affected code?
Is it normal that as a project grows and changes, large parts of code have to be refactored or rewritten from ground up? Is this bad?
Is this a common situation, even in large commercial-style projects?
Yes.
Should I consider investing (a lot of) time in refactoring and maybe even rewriting the affected code?
You going to do that again tomorrow too?
No. Not unless you're actually working on the code you want to refactor.
Is it normal that as a project grows and changes, large parts of code have to be refactored or rewritten from ground up?
Yes.
Is this bad?
It would certainly be a lot easier if we where all perfect, yes.
Yes, this is a common pattern with my projects as well. ABR: Always Be Refactoring. When I feel a new pattern emerge, I try to update older code to match it as well. As a project grows, your experience working in the problem domain influences your style and it's a good idea to be updating older code to match it as well.
As a corollary, if your first project commit is still in your project unchanged a few months later, something is going wrong. I view development as an exploratory practice, and a big part of that is updating old code and ironing out your style. No one knows their final design/API before they start coding. Find any large open source project and walk up its commit history; it happens everywhere.
If you've been working on a drawing or a painting for a while, your style develops sophistication the longer you do it. Also, your first layer or first few sketches are rarely the inked lines that appear in the final result.
A big takeaway lesson from this experience: you're getting better. Or, at least, you're changing. Certainly, from today's perspective, the code you're writing today looks better to you. If the code you wrote back then looks bad today - make it look better. Your responsibility today is not just the code you write today; it is the entire code base. So make it right - and be glad you're getting better.
Yes, this happens. I would even say that it's expected and typical as you delve further into your solution.
Only update your code when you go back and touch it. Don't forget to write unit tests before adjusting it.
It's very tempting to rewrite bad code for no reason, particularly when you don't have a deadline looming. You can easily get stuck in a loop that way.
Remember, shipping is a feature.
Is this a common situation, even in large commercial-style projects?
I must confess here that my belief is that if you design first and code later you can avoid many issues. So I would say here it depends. If one starts with a good design has some company standards in place to ensure the code based on the design follows the same important rules no matter who wrote it then at least you have a chance to avoid such situations. However I am not sure if this is always the case :-).
Should I consider investing (a lot of) time in re-factoring and maybe even rewriting the affected code?
Making things better can never hurt :-).
Is it normal that as a project grows and changes, large parts of code have to be re-factored or rewritten from ground up? Is this bad?
I would say yes and re-factoring should be normally considered to be a good thing when the resulting code is better than the old one. The world never stays the same and even if something was appropriate at some point in time it just may be that it doesn't stand up to the needs of today. So I would say it would be bad if the company you work for would say to you: "you cannot re-factor this code. It's holy". Change (if it is for the better) is always good.
Fred Brooks wrote, "Build one to throw away, you will anyway." While it's not as true as it used to be, it is far from uncommon to not really understand the problem until you start working on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I was wondering how valuable open-source projects are to learn from?
I still consider myself "beginner" due moreso to lack of experience than lack of knowledge- I've read many C/C++ tutorials and taken classes and such, but I just really lack experience. Therefore, even though I understand the major data types and coding techniques, I don't have a solid grasp on what approach to take to use them in my own programming. Therefore, while I continue to read/practice/learn, I have been downloading lots of open-source code (random applications, emulators, games). It is worthwhile looking at them to help learn? I find it extremely interesting, but more often than not just get lost.
Second question, where does one usually start when doing this? Do you hunt down a main() function somewhere? Do you look at headers to see what functions will be available throughout the code and get an idea of what is around to work with?
Please let me know!
R
I personally wouldn't recommend the reading of the source code of open-source projects to a beginner, especially if they're mature projects. It may be overwhelming for a beginner since they tend to be rather large projects with thousands of lines of code, most likely of a non-trivial design.
If you lack experience, then the best way to gain experience is by writing your own programs and taking on your own projects that are of interest to you, in my opinion. You can certainly read other people's code to see "how it's done", but actually trying to implement those ideas yourself in practice does more to help you understand how to write code than just passively reading code. In turn, the gained understanding and experience will allow you to make better sense of other people's code.
It's sort of like math; you may know the formulae, and you can see how mathematicians/teachers/professors/etc. use those formulae, but you won't really understand them until you try them out yourself. Once you do understand them, then the kinds of things mathematicians write will make much more sense.
Try to focus on things you want to do, there's not a lot of point in looking at code for an application that you have no reference point for.
The best place to start would probably be to look at a project like Boost
But formulate a series of application tasks that you'd like to investigate, perhaps graphics, text editing or socket programming... and then work from there.
Getting a good IDE or programmers editor that will help you navigate the code is a major plus.
For example, Emacs + ECTAGS/CEDET/Semantic will help you browse all the functions / classes in a C / C++ project.
I'm agree with #In silico. It's very useful to see other's code, but only when it's a little bit over your level, so that you can learn something. I've seen quite a few projects that were too "over-engineered", so that learning from them when you can't really tell the good from the bad will be a bad idea.
Another thing is to learn from another programmer, when you could ask why he did one way and not another. In this case the difference in levels does not matter.
So I'd suggest programming by yourself, and looking on the other people's code for the same thing after you've tried it. In this way you'll be able to compare the choices you've seen and the decision you've made with someone else (when you don't know a problem in depth, any suggested solution would seem right). You know, In theory, theory and practice are the same. In practice, they are not.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am new to work but the company I work in hires a lot of non-comp-science people who are smart enough to get the work done (complex) but lack the style and practices that should help other people read their code.
For example they adopt C++ but still use C-like 3 page functions which drives new folks nuts when they try to read that. Also we feel very risky changing it as it's never easy to be sure we are not breaking something.
Now, I am involved in the project with these guys and I can't change the entire code base myself or design so that code looks good, what can I do in this situation?
PS> we actually have 3 page functions & because we do not have a concept of design, all we can do is assume what they might have thought as there is no way to know why is it designed the way it is.
I am not complaining.I am asking for suggestion,already reading some books to solve the issues Pragmatic Programmer; Design portion from B.Stroustrup; Programming and principles by B.Stroustrup;
The best and most important thing you can do is lead by example. Do things the right way and try to improve things slowly. You aren't going to fix anything overnight.
Make sure every piece of code that you are responsible for is better after you are done with it. Over time, the system will tangibly be better because of your efforts.
After you build a strong reputation with your co-workers, try go start some code reviews or lunch-training sessions to get everyone up to speed on better ways to do things.
In a nutshell: it will be difficult and frustrating, but it's possible. Good luck.
Your best bet is to NOT to handle it at all. Here are potential problems if you try:
You will be criticized for doing something you were not told to (makes performance reviews go real bad.)
You will have less time to do your own work.
You will not advance your career by cleaning working code- if it is not broke then do not touch it.
Never make enemies with people who control your career- unintentionally implying they are obsolete morons does not help your cause (especially in a bad economy).
Focus on making your own code great. Battling poorly written code is part of the ill of being a Software Engineer. You are in the wrong profession if you will not stand for it.
A little off point but important- You may need to switch jobs or teams if possible once the economy picks up. Mixing with a truckload of bad coders who do not bother to update their knowledge and practices dulls your own programming skills and weakens your marketability.
If you're a junior dev, then the only thing you can really do is write code as elegantly and readable as possible.
If your style is indeed better, other people might notice and say "hey we should adopt this formula"
Actions speak louder than complaints, which is something I noticed.
The present is embodied in Hexagram 47 - K'un (Oppression): Despite exhaustion, there may yet be progress and success. For the firm and correct, the really great man, there will be good fortune. He will fall into no error. If he make speeches, his words cannot be made good.
The future is embodied in Hexagram 6 - Sung (Conflict): Though there is sincerity in one's contention, he will yet meet with opposition and obstruction. If he cherish an apprehensive caution, there will be good fortune. If he prosecute the contention to the bitter end, there will be evil. It will be advantageous to see the great man. It will not be advantageous to cross the great stream.
I was in the exact same shoes before. I got hired as a C++ programmer to 'lead the team' on how to use C++ by an enthusiastic manager. That was about a decade ago. Some of the newer engineers loved me, the seniors despised me. Our system was basically a pseudo-C++ system. It was like C with classes, but it appeared that people didn't even understand the usefulness of things like constructors since they hardly appeared.
You complain about functions that are 3 pages long; we had functions that were 8000 lines long full of long jumps, function pointer casts, etc. One of the seniors even formatted the code with 2-space indentations so that super deep nested blocks can be written without using much horizontal space since the seniors seemed to be allergic to writing functions and procedural programming in general. Someone even inlined a 2000 line function thinking it would make things faster. You might be dealing with some bad code, but I was dealing with the most horrid copy-and-paste code imaginable.
Unfortunately I was very young and cocky. I didn't get along with the seniors, I fought against them in territorial battles over code. They responded by creating coding standards which no sane C++ programmer could follow (ex: it's okay to use operator new, but don't use exception handling, don't use constructors or destructors, etc). As a result I wrote the most bizarre and stupid standards-workaround C++ code just to kind of rebel against those standards since I refused to write C-style code given the reason I was hired (I didn't hate C so much, but writing C code was not part of the job description: I was hired essentially as a C++ consultant), even though the standards made C-style coding the only practical way to do things. I only kept my job because I put in so much overtime to make sure that my code works very well in spite of these ridiculous coding standards.
It wasn't until years later when others started to see things my way that we lifted the silly standards and started writing more natural, easy-to-read C++ code complete with STL and boost goodies, RAII, exception-handling, etc. That isolated the seniors who refused to write code in a more sane fashion and they were finally forced to adapt.
In retrospect, I could have done things much better. The seniors were intent not to allow me to be put in a teaching position, but I think I would have gotten my point across much faster with my head down. The biggest regret I have is trying to work around the impossible coding standards rebelliously rather than getting them rectified through clear and rational discussions. As a result, I have really stupid and obfuscated C++ code in the system which people attribute to me even though that's not how I normally write C++ code. The regular developers I work with understand this, but the seniors still point to it as an example of why C++ is bad.
In short, I recommend that you focus on making more friends rather than enemies. Your friends will support you, and if your way is better and you can clearly demonstrate it, you can isolate the few who will never agree.
Being enthusiastic to code the right way is a good trait to possess and in the software industry we will always encounter other developers who write code that is not quite in line with our "perfect way" of coding. This should never be interpreted as rubbish code, or inept coders, because we all start out like that in some shape or form.
Always respect your peers around you as you want them to respect you. It's certainly not easy to do in an environment that highly regards ego, but attempting to approach a topic like this is never easy.
It's how you communicate
Try different approach angles, remember you are there to learn as much as to render a service.
So commenting on the "poor" code style in an "in-your-face" kind of approach might not be the result you were looking for. So then back up a bit and try approaching the topic with "I was considering the style of code used and have a few suggestions..." and see the difference that gives.
Where I work now, the one thing I've learnt is that it's fine to comment on something that's might not be good quality but then I had better have a better solution to present.
In other words, be prepared to back up your words with useful solutions and not because you feel so.
This is the most basic reason why establishing coding standards and code review processes are a good idea.
I will not write three page functions no matter what coding standards and processes are established, but some people will. They will create 20 local variables at the beginning, without initializing any of them. You'll have pointers and integers with unspecified values. You won't know the exact meaning and scope of each variable. Etc etc.
Try to convince your manager and, later, your team, with solid arguments. Maybe you could start with a shared reading of Effective C++ or C++ Coding Standards. Try to stress the point that, when working this way and creating better code, everybody wins. If they see this as a win-win situation, they will be more open to the change.
I can empathize.
I'm below two senior programmers who have very unique styles that I find frustrating. We have code that consists of one main function that's 1000 lines long. (That is not a typo.) Our coding standards discourage globals, so we make every program one App object. Now our globals are member variables! When we need an iteration interface for C++ classes, why should we use the begin, end, and operator++ conventions, when First, AtLast, and Next can be used instead. We've wrapped up third party libraries in custom interfaces for no good reason. (We've wrapped log4cxx and lost functionality for no reason I can tell, and one of our date classes consists of a shared pointer to a boost::date object with a fraction of the functionality.)
Here's how I've kept my sanity. I've focused on the new languages and tools. This is our company's first project involving Python, and I've spent my time writing utilities and programs there. While the senior programmers code in what they're familiar with, I've got near free rein of all the Python code. I couldn't stand the C++ APIs we use, so I duplicated most of the same functionality in Python in a much more friendly way, and the other developers prefer it too.
Likewise, we have little familiarity with log4cxx and less with boost-build, both of which I've taken time to study in depth and know good enough that people come to me with questions. I've written a handful of resources on our wiki giving usage tips for log4cxx and numpy and other tools.
This is how it is, get used to it or quit and find a place where it isn't like that. You will be marginalized if you criticize their efforts and they may feel threatened if you do indeed write your own, better code or improve theirs. At the end of the day they deliver code and management sees a black box that works and that's all that matters. Plus, you'll be just another kid from college who thinks he knows something about development at a business and laughed at and ostracized when not around. Honestly, a lot of the times these systems are built like this because of shaky requirements, lots of functionality bolted on with time and managements lack of respect for a stable software development process.
Not all companies are like this. I'd start looking for a new job to be honest.
I fervently hope, this is the best opportunity to grow by facing the challenge.As Robert said,try to lead by example.If possible let them adopt your pattern.
You are not alone. I too faced recently, luckily we have support from Senior Management for Code Reviews.
1. Even a single line change for Bug fix should be reviewed online.
Comments on code can be classified as CodingStandard/Suggestion/Clarification/Major/Minor etc
While giving comments to senior you can start with Clarification/CodingStandard rather than Major
You could address the issue of "we are afraid to touch it for fear of breaking it" by writing extensive unit tests. Once you get the unit tests in place, you will be freed to refactor at will. If your unit tests still pass after the refactoring, you can be confident you haven't broken anything.
Just place a copy of "Clean Code" (Martin), "Refactoring: Improving the Design of Existing Code" (Fowler) or "Effective C++" somewhere in the office where people may start browsing the books. From now on, word will spread. Seriously, its never too late to learn! ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When in school it was often a requirement to flowchart the little programs that we wrote line for line.
Those flow charts tended, due to the size of the pictures, to be very large and were often tedious to draw.
It was always to such detail that you were essentially writing code anyway.
I use flowchart/UML style techniques to develop higher level things but when it gets down to actual loops and what not it seems like overkill.
I will often pseudo-code more detailed algorithms but still not to the super fine grained point.
Is this just one of those things where in school things were so tiny there would be nothing else to 'Flow-Chart' so they had use do the minutia?
Flowcharts, no -- Sequence diagrams, yes. I try to keep them at a very high-level to communicate the idea to someone quickly. I do not try to get every detail in. I might supplement with another diagram to show an edge case, if it seems important.
It's great for communication as a sketch -- I think it's not right for a specification (but would be a good intro to a detailed section)
Flow charts for the ifs and whiles of real code, never (in 30 years) found useful.
As a discussion aid for elicitng requirements ... so when we're here, what could happen? ... how would you decide ... what would you do if it's > 95% ... Can be helpful. A certain kin d of user finds such diagrams on the whiteboard easy to talk about.
To be absolutely honest, I am extremely glad I was required to accompany any assignment with flowcharts. They made me think structurally, something I was lacking (and, perhaps, still lacking to a certain extent).
So don't be quick to jump on a "I'm off to play the grand piano" bandwagon, flowcharts really do work.
Not once did I find myself in a bit of a bind in non-trivial logic. After laying out the logic in the flowchart form on a sheet of paper (takes a couple of minutes), it all inevitably becomes clear to me.
Yeah, I agree. The point was to get you to understand flow charts, not to imply that you should use them for line-by-line code coverage.
I don't know why you'd even waste time with pseudo-code except for demonstration, honestly, unless it's some really low-level programming.
I don't use them myself. But a coworker who only programs every once in a while does. It's a very handy way for him to remember the nuts-and-bolts of that program he wrote a year ago. He doesn't do much programming, so it's not worth it for him to learn sequence diagrams and things like that.
It's also the type of diagram that other pple that hardly ever program will be able to read easily. Which in his position is a plus.
I don't find great detail in a flowchart to be very helpful. I use UML-style techniques on a sheet of paper. Use a whiteboard in a group setting. Mid-level class diagrams and sequence diagrams can be extremely helpful to organize your ideas and communicate your design intentions.
Sometimes on a whiteboard to describe a process, but never in actual design or documentation. I'd describe them more as "flowchart-like" since I'm not always particular about the shapes.
We have an in-house application that has some fairly complex workflow in it. A flowchart forms a big part of the spec of this part of the system. So yes, Flowcharts are a useful tool for spec'ing a system. They are also normally understood by non-technical people which is useful if they are part of a user requirements. No, I would not normally use them at a very low level, nor would I expect part of a system to only be spec'ed or documented by flowcharts.
TDD is a good option for nuts and bolts code, if you are so inclined, and it comes with a lot of other benefits.
We have a large organically grown application that has very little documentation, so using flow charts to document components within the application has proven very usefull to the business side of the operation, as even they don't understand how everything fits together.
They aren't at line by line level, but do cover all branches of business logic with the subsequent processing and outputs (although not following strict flow chart rules - some blocks describe multiple processes).