DO NOT REFORMAT FILES about grid

[coppolachan]

Got it. I will find a solution for when the same files appear messy on my editor. Not because of the original formatting style but because of the treatment of spaces. Reformatting of some files was not a matter of code style taste but readability on my side too. I will not apply any LLVM format anymore.

[chulwoo1]

Hi,

In general, I don't know if there is a way to enforce this in a foolproof
manner except for the self-dicipline.

FWIW,

1. specify preferred indentation by hooks and/or script(s)
2. using whitespace-aware tools (diff3,meld,...) for merge

Could help if/when this happens. I recently went through merging Gparity
branch in CPS, and it'd been nearly impossible without 2).

Chulwoo

On Sat, 22 Oct 2016, Guido Cossu wrote:

Got it. I will find a solution for when the same files appear messy on my editor.
Not because of the original formatting style but because of the treatment of spaces.
Reformatting of some files was not a matter of code style taste but readability on
my side too. I will not apply any LLVM format anymore.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the
thread.[AErp_-CS25akvdM8NRUyI9PubcFPRXtaks5q2bmsgaJpZM4Kds34.gif]

Chulwoo Jung
Physics Department
Brookhaven National Laboratory
U.S.A.
[email protected]
1-631-344-5254

[aportelli]

Ok, I have noticed something. Peter, it sounds like your editor is indenting using a mix of spaces and tabs (are you using two different editors?). Depending on how the editor interprets tabs some files looked pretty messed up (e.g. https://www.dropbox.com/s/lc50pb5cbhromau/Screenshot%202016-10-26%2018.33.15.png?dl=0). It can be a real headache to follow the scope hierarchy.

I have determined that the code has been originally indented with tabs having a width of 8. So setting my editor to space indents of 2 and a tab width to 8 the code looks alright.

I think it would be beneficial before a next release to convert all the tabs to 8 spaces, like that the code would look the same wherever it is opened. In general for the future I would say that it's better to only do space-indentation (which is what most code editors are doing for C/C++).

I am happy to audit and prepare for conversion but it would be good to have feedback to be sure everybody would be fine with this kind of solution.

[paboyle]

I'm not happy with auto conversion. I agree autopreparing a list of files with naked \t in them
and manually cleaning makes sense. I'm happy to do this since I'm not happy with the format
rot we've been acquiring and a global edit is required.

[paboyle]

A small comment -- after some thought on indentation and tools,
I'm prepared to drop our "namespace" declarations into macros that look like legal
C++ statements, including a semicolon to avoid fooling C++ aware editors

GRID_BEGIN_NAME_SPACE();
GRID_END_NAME_SPACE();

to prevent attempted indentation of intervening code. This
also leaves code indented by the same amount wether or not we drop the
"QCD" subspace.

[aportelli]

I totally second that, that’s exactly what I am doing in LatAnalyze and the measurement code (cf. https://github.com/paboyle/Grid/blob/feature/hadrons/programs/Hadrons/Global.hpp https://github.com/paboyle/Grid/blob/feature/hadrons/programs/Hadrons/Global.hpp). In principle you don’t need the empty argument (). However, it is a global edit we should be all synchronised when this happens or a lot of conflicts will happen.

Best,

Antonin

On 31 Oct 2016, at 15:15, Peter Boyle <[email protected] mailto:[email protected]> wrote:

A small comment -- after some thought on indentation and tools,
I'm prepared to drop our "namespace" declarations into macros that look like legal
C++ statements, including a semicolon to avoid fooling C++ aware editors

GRID_BEGIN_NAME_SPACE();
GRID_END_NAME_SPACE();

to prevent attempted indentation of intervening code. This
also leaves code indented by the same amount wether or not we drop the
"QCD" subspace.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #60 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAJWuDoR71y_-v_2D2AGV-9-cAuKO364ks5q5gX9gaJpZM4Kds34.

https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png https://github.com/paboyle/Grid #60 (comment)

[coppolachan]

I have no particular preference for this choice, so I can go on with it.

[paboyle]

I plan to do this namespace change at some point soon. I'm clearing the decks to get a bunch of old small items like this done.