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 12 years ago.
I know good programming practices always help in the "long run" for a project, but sometimes they just seem to cost a lot of time. For instance, its suggested that I maintain a header file and a cpp file for each class that I make, keep only the declarations in the headers while definitions in cpp. Even with 10-12 classes, this process becomes very cumbersome. Updating the makefile each time a new class is added dependecies and evthing .. takes a lot of time...
While I am busy doing all this, others would just write evthing in a single fie, issue a single compile command and run their programs ... why should I also not do the same? Its fast and it works?
Even trying to come up with short, meaningful names for variables and functions takes a lot of time, otherwise you end up typing 30 character long names, completely unmanagable without auto complete
Edit :
Okay let me put it a little differently : Lets say i am working on a small-medium size project, that is never going to require any maintenance by a different developer (or even me). Its basically a one time development. Are programming practices worth following in such a case. I guess my question is, do the good programming practices actually help during the development, or they just pay off during maintenance ?
I haven't been working in the field for long, but not slacking off and documenting as I go, defining variables with useful names, etc...definitely saves time in the long run. It saves time when the other developers/myself go back to the code for maintenance.
Not stuck wondering what this variable means, why did I do that, etc! :)
Laziness may pay off right now, but it will only pay off once. Taking the time to do it right doesn't pay off immediately, but it will do so multiple times and for a longer period of time.
Also, there is nothing wrong with really long variable and method names, unless you subscribe to the naive view that most of the time you spend programming is used on typing and not solving problems.
Addendum: If it is hard to name succinctly, it probably needs to be broken down into more modular units. Method or variables that are hard to name is a definite code smell.
Its all about long term supportability. Clearly you have either not been coding on a team or not had to look at code you have written years ago. I can open code I have written 15 years ago and modify it with very small relearning curves if I have given meaningful variable names, while if I have not it will take some time to figure out what I was doing with that X and that H, and why T should not be more than 4.
Try sharing code with 10 people on a team and have each of them just put code in any place they like... I have worked with people like that. If lynchings still had public support, I would have lead many. Picture this... I know I need to modify the signature on Foo.SetFoos(int FoosInFooVille), but I looked for Foo.h and it was not found, well now I just look for Foo.cpp right? Oops, to save... time?... they jammed Foo.cpp into Chew.cpp... so I look there... its not at the top of the file! Do I find Foo in that file and see if its above that... sure... nope, not found... its in Chew.h. Now I am ready to check the SVN log and target my USB powered missile launcher at that jerk next time he passes by.
The downside of the ad-hoc is in the long-run, when it comes to maintenance (especially when the maintenance coders are people other than yourself). Such techniques might be OK for quickie proof-of-concepts, but will cause more problems in the future if you don't rebuild properly.
Yes, it's worth doing it "right" ie good, because, basically it's pay me now or pay me later, and, you're not the only person who will ever see the code.
If it takes you 15 minutes now to do it "good" - how long does it take you 6 months (or more) from now to figure out what was meant - in your own code!
Now, you could use Martin Fowler's 3 strikes idea for refactoring.
First time in the code to fix some thing , notice it could be refactored, but you're too busy and let it go. Second time back in the same code, same thing. Third time: refactor the code.
The effectiveness of programming practices doesn't seem to be your problem, here. What you should be concerned about are the tools you're using to develop. There are plenty of IDE's and other options for keeping your make files automatically up-to-date, for example.
Related
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.
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.
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.
I am developing a project in C++. I realised that my program is not OO.
I have a main.cpp, and several headers for different purposes. Each header is basically a collection of related functions with some global variables to retain data. I also have a windowing.h for managing windows. This contains the winMain() and winProc(). It calls the functions that resides in my main.cpp when events happen (like clicking a button) or when it needs information (like 'how big to make this window?'). These functions are declared in a seperate .h file included into windowing.h.
Is it worth changing this to be OO? Is it worth the work. Is there any better way I can construct the program without too many changes?
All feedback welcome, thankyou for taking the time to read this.
No, I think if it ain't broke, don't fix it.
Any windowing system is inherently OO to a degree. You have a handle to a window managed by the OS, and you can perform certain operations on it. Whether you use window->resize() or resize(window) is immaterial. There is clearly no value in such syntactic rearrangement.
However, as the application grows, you will likely find that many windows are mostly similar and subtly different. The best implementation is boilerplate basic functionality with special functions attached. And the way to do that is with a base class and polymorphism.
So, if you can refactor the program to be more elegant with OO, go for it. If it grows into the OO paradigm with natural evolution, follow best practices and let it be so. But don't just try to be buzzword-compliant.
Two things you need to think about: cost/benefit analysis and opportunity cost.
What is the cost of changing your code to be OO? What is the benefit? If the latter outweighs the former, then I'd tend towards changing it.
Costs include traditional costs such as time spent, money spent and so on. Benefits include a cleaner implementation, leading to easier maintenance in future. Whatever other costs and benefits there are depend really upon your own situation.
But one thing often overlooked is the opportunity cost. This is a cost that should be factored in to your analysis. It's an economic term meaning foregone opportunities.
In other words, if you do convert your code, your cost includes your inability to do something else with that time.
Classic example. If you do the conversion and a customer decides to not buy your software because you're not adding the feature they want, that lost sales opportunity is a cost.
It depends on what you want to accomplish with the project. If not using the OO features of C++ works for you and there are no good reasons to change, then keep going the way you're going. If, on the other hand, you would like to learn more about OOP and you have the time to apply to it, refactoring it to be more OO style will provide you with a great learning opportunity.
I would follow the best practices for working with whatever window manager you are using. Most use an OO style, which you'll automatically inherit (!) as you follow its usage patterns.
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 11 years ago.
I have switched to a new company and I am working on a product that has a huge code base without documentation. I want to quickly get acquainted with the design and the code flow of the product so that I may become a productive member ASAP
Slowly and steadily one does gets to understand the code, but what should be the best and smart way one should approach the code base so that he understands the code quickly and start delivering?
Note: I tried my hands on Star UML and tried to reverse engineer the class diagrams so that I may have a rough idea of the product internal designs but failed miserably.
EDIT: The question is not about gaining knowledge about what the product does but how the internals are designed.
Fixing bugs and Debugging using breakpoints does provide one way of achieving this but I was looking if there is even a faster way we could achieve this
In Keith's Words:
This may work for some code-bases, but in general I think its a bad idea. You tend to be too focused on the details, while at first you want to get the big picture: what the classes are, what the communication patterns are, etc. Plus, if you have a distributed application (client-server, n-tier, etc), or code that takes a long time to run it may not be practical to run it through a debugger
I'm a contract engineer, and this situation is routine several times per year—for the last few decades.
I find it quite helpful to first run the application and play with it—before looking at any code:
What the heck does it do? If necessary, read the user documentation.
What happens with extreme values?
What if I leave out some values?
What happens if I click on a control rapidly?
Is there any way to misuse the program?
Explore the edges of the application: are there seldom used or hard-to-find sub-menus? Is there a configuration facility which exposes more functionality?
While I'm doing that, I'm constructing a mental model of how I would have implemented it. Surprisingly, this user-oriented first encounter with the product usually causes my understanding of the application to be head and shoulders above the developers who have worked on it for a long time. A side effect of this approach is that I tend to find quite a few bugs (often quite an avalanche of them), and think of quite a few improvements which should be made.
After that, I look at the general structure of the program, whether it be modules, classes, files, or schema. Not looking at individual lines of code, except those showing the program's architecture. Once I think I understand over half of the structure, I try to make a small bug fix or improvement—something which takes a few minutes to write, but may take hours to properly understand. If it works, I make a slightly bigger change somewhere, preferably in another section of the code.
In this way, I've found it possible to understand well enough approximately 50,000 to 100,000 lines of code per day.
If you have a development environment to run the code in the best way I've found is to use a debugger and watch the flow of code while executing it. You can setup break points and step through it to see how the code interacts.
The way I have always learned, besides just reading through the code / data model is to start fixing some bugs. That gives me exposure to various parts of the system, and having the 'purpose' while reading the code makes it a bit more meaningful.
Ask everyone you can find for help and ask them to ask anyone else they think could be helpful.
There are tools which suck up the source code and draw pictures. Try Enterprise Architect from Sparx. It's under $200 per seat and will show you the object layout very effectively.
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 11 years ago.
A few weeks ago, I was assigned to evaluate all our programmers. I'm very uncomfortable with this since I was the one who taught everyone the shop's programming language (they all got out of college not knowing the language and as luck would have it, I'm very proficient with it.). On the evaluation, I was very biased on their performance (perfect scores).
I'm glad that our programming shop doesn't require an average performance level but I heard horror stories of shops which do require an average level.
My question are as follows:
As a programmer, what evaluation questions would you like to see?
As a manager, what evaluation questions would you like to see?
As the evaluator, how can you prevent bias in your evaluation?
I would love to remove the evaluation test. Is there any advantages to having an evaluation test? Any disadvantage?
Gets things done is really all you need to evaluate a developer. After that you look at the quality that the developer generates. Do they write unit tests and believe in testing and being responsible for the code they generate? Do they take initiative to fix bugs without being assigned them? Are they passionate about coding? Are they always constantly learning, trying to find better ways to accomplish a task or make a process better? These questions are pretty much how I judge developers directly under me. If they are not directly under you and you are not a direct report for them, then you really shouldn't be evaluating them. If you are assigned in evaluating those programmers that aren't under you, then you need to be proactive to answer the above questions about them, which can be hard.
You can't remove the evaluation test. I know it can become tedious sometimes, but I actually enjoy doing it and it's invaluable for the developer you are evaluating. You need to be a manager that cares about how your developers do. You are a direct reflection on them and as they are of you. One question I always leave up to the developer is for them to evaluate me. The evaluation needs to be a two lane road.
I have to also evaluate off a cookie cutter list of questions, which I do, but I always add the above and try to make the evaluation fun and a learning exercise during the time I have the developer one on one, it is all about the developer you are reviewing.
I would first consider not necessarily the number of lines of code, but the value of the code that the person adds as reflective of course to what they are assigned to do. Someone told to maintain code verses building a new app is very different. Also consider how the person uses new techniques to make the code relevant and updated? How maintainable is the code the person creates? Do they do things in a manner that is logical and understandable to the rest of the team? Does their coding improve the app or just wreck it? Last and not least does their coding improve over time?
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person. One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding, etc.
What about getting everyone's input? Everyone that a person is working with will have a unique insight into that person.
That would work if (1) evaluation is conducted with open doors and (2) you've worked with that person on one project or even on the same module. As the person evaluating them, I couldn't judge the programmers who I didn't directly work with.
One person might think someone is a slacker, while another person sees that they are spending a lot of time planning before they start coding
Unfortunately, this is debatable. Someone who looks like a slacker might be in deep thoughts, or maybe not. And is someone who spend a long time planning, necessarily a bad programmer?
I believe a good evaluation question would be able to answer this.