A co worker of mine asked me to review some of my code and he sent me a diff file. I'm not new to diffs or version control in general but the diff file was very difficult to read because of the changes he made. Specifically, he used the "extract method" feature and reordered some methods. Conceptually, very easy to understand but looking at the diff, it was very hard to tell what he had done. It was much easier for me to checkout the previous revision and use Eclipse's "compare" feature, but it was still quite clunky.
Is there any version control system that stores metadata related to refactoring. Of course, it would be IDE and Programming Language specific, but we all use Eclipse and Java! Perhaps there might be some standard on which IDEs and version control implementations can play nicely?
Eclipse can export refactoring history (see 3.2 release notes as well). You could then view the refactoring changes via preview in Eclipse.
I don't know of compare tools that do a good job when the file has been rearranged. In general, this is a bad idea because of this type of problem. All too often people do it to simply meet their own style, which is a bad, bad reason to change code. It can effectively destroy the history, just like reformatting the entire file, and should never be done unless necessary (i.e. it is already a mess and unreadable).
The other problem is that working code will likely get broken because of someones style preferences. If it ain't broken, don't fix it!
I asked a similar question a while ago and never did get a satisfactory answer. I'll be watching your question to see what people come up with.
For your particular situation, it might be best to review the latest version of the file, using the diff as a guide. That's what I have been doing in my situation too.
The Refactoring History feature is new to me, but I like the way it sounds. For a less tool-specific method, I like sending patch files. The person reviewing just applies the patch and reviews the results, and then they can revert to the version in version control when they're done.
Related
Is this possible? If so how do I do this?
The code is in C# and we are using TortoiseSVN.
I simply want to auto format the code on every checking.
Thanks a lot
With a pre-commit hook script, you could do that, yes.
But I'm sure that you will remove that script after the first commit because you'll get into big problems.
If you modify the data that gets committed, the client doesn't know about that. So after such a commit where your script 'fixes' the formatting of a file, the file content in the repository is different than the files in your working copy. But your working copy still thinks it's up to date with the repository (after all, it's modifications just got committed).
So on the next update, you'll get into hell - broken working copy, angry users, ...
And of course, you might break the build - auto formatting has that effect sometimes.
You can of course implement a hook script that checks for a correct formatting and returns an error if it doesn't, that's perfectly fine.
And since you're using TortoiseSVN, you can try doing the formatting in a client-side pre-commit hook.
You're touching on holy-war ground. Mussing with people's formatting is asking for pitchforks and torches.
My recommendation: Don't.
Not to mention, if you're talking C#, and your developers are using Visual Studio, VS has a lot of auto-formatting tools. Just by entering that closing curly-brace and VS can/will auto-format your code.
A better solution may be to get all your developers to use the same auto-formatting settings.
Tools -> Options, Text Editor -> C# ->Formatting
These settings are exportable, so if you can get the team to agree to use the same code-formatting settings in VS, you can avoid the trouble of performing it in your source control system which is better left to do what it does best.
If you're hell-bent on doing this, a pre-commit hook, like others have said, is the way to go. If you're SVN server is running on Windows, might I recommend CaptainHook for writing your hook scripts? Plugin-able hookscripts that you can write in any .NET language.
like most people here I agree adding a pre-commit-hook that rewrites their code is bad, however you can have a pre-commit hook that rejects code that is not formatted to your coding practices and inform the user of such error.
I think you can do this using a pre-commit hook in your repository.
Edit To the people who think this a bad idea (I'm not saying it isn't): It's not uncommon for organizations to enforce a specific code style or code formatting. Sometimes these rules can be quite pedantic and strictly enforced, and although they are usually human actions involved in this (i.e. formatting to the correct style before you commit anything to the repository), automating the process can sometimes be useful.
An alternative approach might be to do the verification automatically before the commit, but still allow the commit even if the check fails, but then only send an e-mail or some other notification to indicate that someone didn't follow the style.
I highly recommend it.
Use a pre-commit script or better still, find a way to do it automatically in your IDE (pre-commit will push the changed file to the client). Eclipse can auto format on save.
The rationale for this is that if developers format differently you'll find files which have commits on them where the commit is only a formatting change and it will cause endless confusion.
A common formatting pattern is a very good idea. It'll be hard to introduce, but it'll be worth it. All changes will be real changes, and not just formatting changes. In my experience developers will see the benefits and accept it.
I've worked with cvs and java and used jalopy to auto format. We were using a branching system so it was mandatory, and it worked very well.
It is possible, but also a very, very bad idea.
No automatic code formatters are perfect, and I can almost guarantee that it will tick people off.
That said, if you want to do it, look into using pre-commit hooks.
Is the SVN server running on a Windows or Linux system? And what code-formatter do you want to use?
Let me rephrase so as to put the pointy end of the question more directly: Neo4j worked with Roo at one time (maybe not perfectly, but some simple examples published in at least one book apparently did work). Why can't I download the version of Roo that the author used and duplicate the author's results?
A shallow answer, of course, is that software dependencies not part of the Roo distribution have changed.
A deeper question is, Why does this happen? That is, why can't I download the versions of the software providing those dependencies to Roo that were current at the time of the author's writing and expect to be able to duplicate his results?
It's at this point that I'm a little stuck and I can't see why that should be. I don't seem to have any way to be able to identify what those versions might have been. It seems like that ought to be a critical part of Roo's configuration management. But, come to think of it, I don't recall this sort of record-keeping to be part of typical practice except where the RPM package manager is involved. Now, maybe my perceptions as to this point are flat out wrong. But if they're not doesn't the usual way of doing open-source development need to be upgraded at this point? Or maybe I'm so completely wrong that you can turn back Roo's clock, so to speak. If that's the case, will someone please tell me how to turn it back so that Neo4j works as well as it once did (However well or badly that was I don't really care. I just want to replicate results.)
Is that a better way of expressing and attacking the problem? I'm trying very hard to prop up one of the couple of books written to date about Roo. Frankly I'd like to see the book's author(s) or publisher wade in and help me or rebut me, because the book's still being sold. If the ongoing example is as badly broken as I think it seems to me that it would be wrong to continue selling the book or, at least, selling it without a clear warning to the reader. O'Reilly published the book in question and I have a high subjective opinion of their business ethics--a high enough opinion that I wonder if I'm getting everything wrong.
Generally when you're wrong, you can depend on 100 people to tell you so (plus another 10-20 to tell you you're wrong on points that you did get right and another 5-10 that seize on some basically irrelevant point and contradict you apparently ust fof the fun ot it, without in any way moving the discussion forward--a cooperative concept they seem incapable of grasping let alone following). But I, and others who've asked essentially the same question, hear nothing but the crickets. Chirp-chirp???
mv (sorry: I wasn't immediately able to find the markup syntax used to notate the ids of members) asked a question about the future status of Roo's support for Neo4j, which appears to have foundered. A related question puzzles--and frustrates me--mightily. Neo4j was supported under Roo 1.1.4 but when I try code that apparently worked when 1.1.4 was current (from Josh Long's book Getting Started with Roo), the code fails in exactly the way it fails under 1.2.5 (and the upcoming release, 1.2.6). In other words, it appears that support for Neo4j was removed retroactively, so to speak.
My question follows as a generalization of that observation: Under what technical circumstances (I don't wish to consider possible legal reasons) would it be good (i.e., sound, practical, necessary. &c.) to retroactively alter the behavior of a released version of a software product?"
Currently, I'm finding this decision as respects Roo inconvenient and so I think I may overlook good reasons for such a decision. Please note, however, that my question doesn't specifically pertain to Roo. For one thing, I don't relish a discussion in which participants work to make the Roo team look bad. For another, I'm interested in the general case, not merely the particular case of Roo. Actually it seems to me at the moment that the absence of retroactive inconsistencies in behavior is a necessary condition for robust systems. I mean, for example, at exactly what time did the inconsistency begin? Was it during or after the stated duration of viability of the release in question. Probably I'm wearing my Chicken Little hat but right now it seems to me as though retroactive inconsistency has "Humpty Dumpty" written all over it.
That being said, I suppose I'm sneaking in a second question, but I would very much appreciate being told that my premise as respects Roo is inaccurate; that is, Neo4j can somehow be used under some appropriately old released version of Roo. In that case, I would also be immensely curious to know how this might be accomplished. Roo doesn't require any set up configuration so there appears to be no opportunity for a configuration tweak. Actually the only stated requirements are a JDK and Maven under Linux, OS X, or Windows. But, the addon command apparently queries a database of some sort. Perhaps that is an unstated dependency responsible for retroactively inconsistent Roo behavior.
Having snuck in a second question, I'm finding it difficult resisting temptation to go for a third question. If I were to succumb, the question would be this: How, in the particular case of Roo, is it possible (assuming that the release code has not been surreptitiously changed) that the behavior of an old release has been changed? It seems to me that the answer must lie in Roo's dependencies. But, assuming none of the dependencies has retroactively changed its behavior, can Roo do so without actually modifying the released code? It seems to me that it cannot, in which case I'd be exceptionally eager to know which dependency (assuming there is only one) has retroactively changed its behavior, and why. But. I think I may yet find the resources to master even the quite strong temptation to pose that question. :-)
Long question,..
Running an old release should duplicate it's behavior, but there might be inconsistencies due to various circumstances. It will be hard to pinpoint those without some more eleborate description of the problem and a stacktrace (if available).
You state that you believe the software dependencies of the roo-distribution might have changed, but this should not be the case: maven, acting as your dependency manager, should take care of that as long as there are no SNAPSHOT dependendencies in your pom.xml (or rather, in the dependency tree).
But there are other reasons the behavior might be different now. It could well be the version of the JDK you use. These also should be backward compatible but on wikipedia I saw that spring roo doesn't support Java 8, for example.
Then there is your operating system, but I believe it would indicate some sort of bug if that would be the issue now.
Finally I would look at third-party addons of spring roo. Unfortunately I am not familiar with them, but it seems to me that a third party add-on is downloaded with some command that doesn't necessarily ask for the 'correct', compatible version of this addon.
I hope this answer to the title-question helps you. your second and third question did help me in formulating this answer, but generally it would be a good idea to make separate posts for the snuck-in second and third question.
This question comes from previous experiences with svn.
We had a problem where our code was badly formatted, mainly because of the increase in developers at the time who did not adhere to our formatting guide for various reasons. So there was discrepancies in code formatting for quite a bit of time. Additionally the codebase was quite old as well, so it was probably going on for years.
Anyway, there was a suggestion to format all touched classes in new features into our agreed standard code formatting style. Other developers were against this mainly because:
You can't use an annotation style view of the code, so you can't see what features a particular line of code is related to.
In the end, we ended up rejecting this idea and only did formatting for newly introduced class files. For new code in existing classes, we only ensured that the lines that were edited were indented correctly.
We are mostly eclipse users, but I think that this feature is available in other ide's as well (just checked online for netbeans and intellij).
For an additional bit of context, the codebase in question was fairly mature and there was a fair balance between support work and new feature work. Sometimes new features were split into phases, so this is also something to consider.
So the question(s) are:
Was this the correct approach? Is it reasonable to reject "code formatting commits" just to preserve an annotated view of the code?
Are there better ways of doing this? My opinion here is that maybe there should have been a commit hook that does automatic formatting, not sure if something like this is exists or is even valid though?
You do not want to do this in a hook. Not only is it a really bad plan to have a hook edit the source in any way as it's in transit, but the error the user will get is going to suck (it would be impossible to tell the user all of the errors in a meaningful way on an error message). I'm not a fan of enforcing style in general.. but if you must, I recommend a three part plan
Define and document your coding style. What you come up with isn't as important as the discussion.
Export configs for editor and share with team. this will be editor dependent. you want to make it stupid easy so that the drudgery of indentation and other syntax things is handled automatically.
Have your CI enforce that style. If you really want to enforce it, you'll do it here. likely with something like checkstyle. This will generate a fancy report that will show and display all the errors.
I've worked on teams that did this really well... the standard was pretty flexible, everyone felt they had input so when the build failed there was no grumbling. We fixed it and moved on.
I did work on a team where an irrational fascist believed that the style was more important than the completeness or correctness of the code. It sucked.
Personally I'd stop at step two and see where that gets you before moving on to step 3.
In Eclipse, under Preferences > Save Actions, one can enable the Auto Formatter which formats the code on file save. You can configure a set of Formatting Rules and Export Preferences File to send to your developers (or have the leading developer do it) for them to Import Preferences File, so the code is automatically formatted as they are developing it.
A standardized auto-formatter would help eliminating the in-similarities in code style which causes non-codebase changes in the SVN.
I think it would be perfectly fine to do a one off code formatting commit for the old classes in your repo, it's definitelly better then having ill-formatted code all around the place.
As for IDE's Intellij and Eclipse can do formatting on save, but I'd be against doing it in a hook because it's not aware about what you're coding in, and wouldn't trust that on a script. But that can work as well but need to make sure that what you're using for formatting is well up to the task
I am looking for a tool/plugin for JIRA/Eclipse that can,
Execute FindBugs over the code.
Based on generated report, provide a UI to mark bug or improvement in JIRA depending on the case. Note that the text should be copied directly from report to marked issue in JIRA.
Looked around on internet but could not find one. Please suggest if such a requirement is fulfilled by any other tool like PMD, etc.
Other answers have suggested that you should create a single task to deal with fixing FindBugs warnings. I'm not even sure that you should do that. The problems identified by FindBugs might not even be problems, and even if they are problems, might have little to no impact on the quality of the system under development. They really should be reviewed by a human instead of blindly added to a bug tracker as something to fix.
My suggestion would be to incorporate FindBugs (and any other static analysis tools) into your build process as well as your code review process. As part of your build process, it would generate reports after every build. As developers work on modules, they would be able to consult the FindBugs reports for those modules and address them as-needed. As part of the code review process, a developer (either the author or a reviewer) can manually launch FindBugs over the code under review, analyze the reports, and include specific issues as action items to handle coming out of the code review using your team's methodology.
That said, if you are using FindBugs 2.0, there appears to be a JIRA plugin to facilitate what you want to do. It appears to have limited support and must be built from source, but it might be something to look at. As I mentioned above, though, I wouldn't recommend it.
Does this really make sense? I mean, creating one JIRA issue for every FindBugs marker will take more time as fixing it immediately in most cases. Not to mention the huge amount of issues in which this will result. The developer will have to spend more time in closing JIRA issues than in fixing them.
I would create exactly one issue for this: "Fix FindBugs warnings before release".
I think I'd use one JIRA Task that says:
"Run FindBugs. Record the report somewhere. Fix the most obvious problems. Run FindBugs again and record the final report." That way everyone can see that work was done, and what work it was.
Storing information about each problem found by FindBugs in a JIRA issue would lead to a large number of issues, and many of them would quickly become outdated.
For the first part you can write a script in any language (I would have used python) to Execute FindBugs and manipulate the generated report in any way you wish and than implement the secod part by using the Jira remote API to create issues or a single issue as others suggested. To pick an API most suited check the manual for your Jira's version to see the full API capabilities.
I have just created a mid-sized web-application using Java, a custom MVC framework, javascript. My code will be reviewed before it's put in the productions servers (internal use).
The primary objective of building this app was to solve a small problem for internal use and understand the custom made MVC framework used by my employer. So, my app has gone through MANY iterations, feature changes and additions.
So, bottom line, the code is very very dirty and this is my first "product level" Java app.
What are your suggestions, what are some basic checks/refractoring I should do before the code review?
I am thinking about:
Java best practices (conventions)
Make the code simple to understand for the developer who will maintain it. (won't be me)
I noticed, I have created some unnecessary objects and used hashmaps/arraylists where could have easily used some other Data structure and achieved the solution. So, is that worth changing?
Update
Your Code Sucks and I Hate You: The Social Dynamics of Code Reviews
If you did not already, (assuming you use an IDE like eclipse)
get plugins checkstyle and findbugs
go through their configuration and tune to your style
run them on your code
resolve all issues reported
you can also tune the compiler warning setting of eclipse itself and possibly make them more strict in what is reported.
Look at code structure:
get plugin jdepend
investigate your package structure
Code against interfaces (Map, List, Set) instead of implementation classes (HashMap, ArrayList, TreeSet)
Complete your Javadoc and make check it is up to date after all refactorings.
Add JUnit tests; if you have no time left to test the whole application, at least create a test for every bug you find and solve from now on. This helps "growing" a test set as you go.
Next time design and build your application with the end goal in sight. Always assume that the next guy having to maintain your code will know how to find you :-)
Unit tests, and they should be automated as part of your build. You should already have these, but if not, do it now. It will definitely make the refactoring easier, as well improving your general confidence in the code (and the guy who will be maintaining it).
Logging.
One of the more overlooked things is the importance of logging. You need to have a decent logging methodology put in place. Even though this is an internal app, make sure that the basic logs can help regular users find issues and provide more detailed logging so that you (the developer) would know where to go.
Comment your code, explain why it's doing what it's doing and what assumptions have been made.
Try to reduce the amount of mutating state.
Try to remove any singletons you may have.