|
hi
i want to find a full ui component for .net2(vs2005) that supprt Dockable tool window(like solution explorer foe .net)
and Dockable toolbar and ui like IDE of .net
no one knows?
|
|
|
|
|
tonato848 wrote: no one knows
Nope, the rest of us know how to use the search function or Google. 
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
When it comes to coding, we may/will have to write and get approved a storyboard for what we are about to write/develope.
Once that is done, we do the work and test it to a appropriate to the change. For it to be checked-in, the code must pass a peer review. This can/will require:
Changes to conform to coding standard
Functional changes to how things are implemented
Changes to make things understandable to others (comments)
Bug fixes spotted by reviewer (not common)
So all code is reviewed at least to a minimum level.
But with a max team size of 4 its reasonably managable, although egtting someone to be available to do the review as and when can be a bit of a pain.
If you vote me down, my score will only get lower
|
|
|
|
|
On one hand, code reviews may help to eliminate lots of simple coding errors. Such code reviews are performed from the pure coding point of view, without touching the in-depth design. Thus, they are intended to be quick and selective. Usually they don't add excessive work load.
Quick code reviews have a problem, though. The code we wrote is merely the implementation of a design. Withour understanding the design assumptions and decisions, it is hard to really understand the code. When the second developer takes over some code from the first, the easiest thing he/she can say is that code is crap. Because the second person doesn't understand the design (assuming the first has done some careful design).
We have tried to perform detailed code reviews, aimed to understand and verify others design, but with little success. It's not entirely impossible, but it usually is limited or abandoned due to tight budget, schedule and resources.
In summary, code reviews could have different objectives. It appears that only some of them are actually acheiveable. I found quick code reviews are sometimes beneficial.
By the way, in my company we very rarely do code reviews now.
Best,
Jun
|
|
|
|
|
Can anyone recommend a good automatic code review tool?
Dividing a code review to 2 parts of syntactic and semantic reviews, I'm convinced there are part of it which could be automated. A good tool should be easily configurable for example regarding the naming conventions.
I don't think the whole code review process could be totally automatic, but an automatic tool can reduce the effort to a necessary minimum.
Thanks,
Erez Nassimi
asaly@netvisio.net
erezna@amdocs.com
|
|
|
|
|
Just a correction:
asaly@netvision.net
|
|
|
|
|
|
Screw code reviews... pair programming is the way to go!
|
|
|
|
|
From experience, pair programming only works well if the two programmers are on the same level of competence. If not, it's just waste of manpower...
--
Secreted by the Comedy Bee
|
|
|
|
|
When I was at a place that had code reviews we all benefitted from it, but I think people expect too much from them.
What I see as the major benefit is sharing familiarity with the code base, so there aren't any lone rangers where noone else understands their code. At least through the review process you can help familiarize others on the team as to what's going on inside. Sole ownership isn't a good idea in my opinion, as if that developer leaves the team, then you have the overhead of reverse engineering what they did without the benefit of their explanation.
As to doing reviews to nitpick style, well, in large organizations this might be a must. But in small teams this isn't as beneficial, as hopefully everyone agrees to a common coding style. Taking a bit for granted there, but that's my experience.
But to have a second set of eyes asking: "Why did you do it that way?" is very helpful at times, because you might not have seen a simpler way, or you might better understand it yourself through the excercise of explaining it.
We don't have them where I'm at now... I tried.. but a few blank stares and a couple of comments "That would be nice" was all I got. 
So now I have 30,000 lines of code noone has reviewed, and I couldn't imagine having to figure it out as a greenhorn. I'm not going anywhere that I know of though... 
This statement is false.
|
|
|
|
|
... can be useful. We do them for CMMI processes but they aren't always done right. The rules are (basically) comment on the code and not the person and are the standards being followed.
If the managers (or someone) doesn't enforce these rules the reviews aren't worth spit. I have walked out of reviews after personal attacks. One person who was FOTB (Friend Of The Boss) said my code was wrong becasue I followed the standards and not what he thought should be done. The boss sided with him. WRONG way of doing reviews.
Also, we have been bogged down in reviewing a bunch of short specific modules with no complexity, no branching or algorythms implimented, that could have been skipped.
|
|
|
|
|
I am firm believer of Code reviews to improve the performance of the team, and assure the maintenance of code.
I had the chance to implement this technique once, on a small team of developer’s and we really enjoyed and help everybody to keep standards, avoid mistakes and problems on the long run, help to teach and grow the less talented, and the best allow anybody to be able to understand the coding style of the coder’s on the team and fix any problem with out being the original coder around. We start to run in problems when we hire a developer that he was extremely jealous of his code, he never wanted to go in code reviews, and he sabotage all the code reviews. I never imposed too much because by the time I was almost gone from the company.
Since that job I try to convince the manager’s and the teams where I being working, with out luck up to now. To short of time, too much greedy to share the code or managers that doesn’t see the value for code reviews. Even when I came out with an idea of code review that is more like pair programming. My idea was to let the developer under less stress to review the latest code done. But I never was able to sell it.
|
|
|
|
|
I finished a code review before. It was great event for me.
I could use the chance to show off how and what I did in the past months.
I could use the event to get feedbacks from my colleagues and solved ignored problems at earlier time.
|
|
|
|
|
yes we do, in order to maintain our CMMI certification level...
|
|
|
|
|
I believe you're at a company whose name starts with the letter A. Which level are you at?
We are at level 4 and don't do any reviews, at least in my team.
Cheers,
Vikram.
"whoever I am, I'm not other people" - Corinna John.
|
|
|
|
|
Vikram A Punathambekar wrote: I believe you're at a company whose name starts with the letter A
i am, as you can read in my bio
we've been certified level 3 last month... but planning to reach level 5 next year.
|
|
|
|
|
Apparently not:
"Yes, we sometimes to code reviews"
Todd Smith
|
|
|
|
|
Comes from the explaining it factor. When you have to explain your code to another person you will get an immediate WTF if you mess something up. However, most reviews are merely an exercise in formality, a necessary step with no real consequence. It is very rare that some reviews my code enough to point out a logical error. There just isn't the time for them to get in the same zone.
I would rather limit code reviews to important sections of code. Snippets that are boldly going. Then the time can be spent to really delve into it.
However, if unit tests are used, are reviews as necessary? Perhaps, in most cases, the unit test can be reviewed exlusively.
On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage
|
|
|
|
|
I'd be very interested in hearing other folk's experiences with code reviews. I've been through a handful of them and they seem to just boil down to folks asking how the code works and then pointing out minor things like "that variable name doesn't follow our coding standard".
Also, do you folks actively review the code _before_ the code review and bring notes about the code or do you just flash it up on a projector and hope somebody can catch something?
Like I said, it'd be interesting to hear other's experiences with code reviews because in my experience I haven't found that they really benefited the code and/or developers involved.
|
|
|
|
|
|
Many years ago I worked with a team that did very effective code reviews. These reviews were much closer to "inspections" rather than reviews.
About a week prior to the review meeting, the person who wrote the code circulated it to the team and maybe one outside reviewer, along with specifiying roles or tasks for these reviewers. These roles/tasks included - code standard compliance, OO structure, proper system decomposition, proper layering, etc. When the review was conducted, the first task was to ask each participant how much time they spent preparing. If the time wasn't deemed sufficient, the meeting was rescheduled and those who didn't prepare were asked to devote some time to this.
We probably reduced our serious defects by 50% based upon these reviews and the code maintainability went up dramatically. I've since been workinbg with a group of people who don't understand the purpose or benefits of code reviews. I've consistently offered up my code for review, but the only comment I get are "I don't like that variable name", or some other useless rermark. I've also gotten commenst like "the code is done so we don't want to change anything, do we?" My only sollace is that the defect rate within my code is less than 1/2 of any other team member's - maybe they need the code reviews.
Well executed code reviews are the easiest way to improve the quality and maintainability of a system. Studies have shown a payback ratio from 2 to 5 times the cost of doing the review - money and effort well spent! Plus, it is an opportunity to teach and learn better techniques.
Dale Thompson
|
|
|
|
|
Dale Thompson wrote: Well executed code reviews are the easiest way to improve the quality and maintainability of a system. Studies have shown a payback ratio from 2 to 5 times the cost of doing the review - money and effort well spent! Plus, it is an opportunity to teach and learn better techniques.
There's a section on code reviews in Steve McConnell's Code Complete 2nd edition, where he says that code reviews are far more effective than testing in reducing code defects. However, as suggested by this survey, they are hardly ever done and when done are often done poorly. McConnell also describes how they ought to be set up.
I couldn't see a discussion of this in McConnell's second edition though.
Kevin
|
|
|
|
|
Yep, most of the bugs in our production system came from hotfixes where the coder failed to ask for a review.
"Oh its a small change, its gotta be right."
This statement is false.
|
|
|
|
|
Chris S Kaiser wrote: "Oh its a small change, its gotta be right."
They're often the most dangerous!
Kevin
|
|
|
|
|
We would raise our hand and shout in the room: "Anyone free for a code review" and rarely would there be silence. We did this for every checkin. It was great for short pieces, but longer ones required a bit of scheduling and patience.
This statement is false.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
