Actually, the coding style should have been defined before (aka is the top priority) the first unit test was written. And the latter should have been written before the first code was written :-P<div>Defining/changing/applying coding style might be a good thing to do in VTK 6.0 (higher priority) as it might change the API. Code coverage (and fixing bugs) can always be done in succeeding minor versions.</div>
<div><div><div><br></div><div><div>Concerning your 2nd question (in your first email), if it comes to a vote, I would vote in favor of always prefixing with the namespace of the external library (here std::), as long as it is the standard namespace name (std:: and not vtkstd::). It can't hurt to be specific.<div>
<br></div><div>Julien.</div></div></div><br><div class="gmail_quote">On Wed, Sep 19, 2012 at 4:56 PM, Bill Lorensen <span dir="ltr"><<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">David,<br><br>There is not style checknig in VTK, nor is there an consistent style in VTK. Years ago we had a style and enforced through a third party package.<br>
<br>ITK enforces style with KWStyle and we have nightly tests that check the style.<br>
<br>To be honest, style is pretty low in priority versus code coverage and valgrind.<span class="HOEnZb"><font color="#888888"><br><br>Bill</font></span><div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">
On Wed, Sep 19, 2012 at 4:52 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't want to be so strict about formatting that we start using<br>
<br>
<a href="http://uncrustify.sourceforge.net/" target="_blank">http://uncrustify.sourceforge.net/</a><br>
<br>
as another pass before commits can be pushed to Gerrit, but it would be nice to have a "style file" for uncrustify (or a similar tool) that embodies the VTK code style so less code review time is spent on formatting and more on the logic, documentation, tests, and organization.<br>
<br>
David<br>
<div><div><br>
On Sep 19, 2012, at 4:40 PM, "Marcus D. Hanwell" <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>> wrote:<br>
<br>
> On Wed, Sep 19, 2012 at 4:06 PM, Bill Lorensen <<a href="mailto:bill.lorensen@gmail.com" target="_blank">bill.lorensen@gmail.com</a>> wrote:<br>
>> Folks,<br>
>><br>
>> There has been some recent turmoil regarding the use of std::cout in tests<br>
>> versus cout. The current style guidelines recommend the latter.<br>
>> First, why is this even an issue. Second, can we amend the style to allow<br>
>> std::cout? Much c++ code I see uses std::cout.<br>
>><br>
>> I'd much rather spend time improving VTK'sl ow coverage that argue over what<br>
>> seems to be a non-issue.<br>
>><br>
> I guess I was the source of the aforementioned turmoil. I think it is<br>
> important to stick to a common style, and actively changing test code<br>
> to not match the style seems bad to me. I don't see the point in fully<br>
> specifying std::cout when we have brought it into the global<br>
> namespace, but if there is a strong feeling we should then my point<br>
> was simply that we should specify that is the preferred style from<br>
> this point forward (or that either is acceptable).<br>
><br>
> If we all start modifying the VTK coding standards then our code will<br>
> be far less consistent, and harder to understand due to using several<br>
> styles. If there is general agreement on relaxing some parts of the<br>
> style I really don't feel very strongly, but I think it should be done<br>
> deliberately rather than on an ad-hoc basis.<br>
><br>
> Where would you draw the line if this should be relaxed? Could<br>
> standard indentation be used instead of the special VTK indentation in<br>
> classes I author? I am sure we don't want to allow that, but it does<br>
> require some definition on what is strictly required and what is<br>
> advised/optional.<br>
><br>
> Marcus<br>
</div></div>> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
><br>
<br>
</blockquote></div><br><br clear="all"><br></div></div><div class="HOEnZb"><div class="h5">-- <br>Unpaid intern in BillsBasement at noware dot com<br><br>
</div></div><br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><br></div></div>