moskewcz / boda

Boda: A C++ Framework for Efficient Experiments in Computer Vision

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Code indentation

aryamazaheri opened this issue · comments

I am trying to find the right way to see the code with the correct indentation. But, I couldn't find a solution yet. In every editor (vim, emacs, sublime, CLion) which I tried, I see 2 spaces indentation and sometimes I also spot a tab indentation.
For instance, in rtc_prof.cc line 75, I see a tab at the beginning of the line. But other lines have mostly 2 space indentation. Would you please correct me if I am wrong?

in short: the indentation isn't wrong per-se, but it is non-standard in two ways: the basic offset is 2, and there's a mix of tabs and spaces for indenting. hows that for a terrible compromise solution in the tabs-vs-spaces war?

so in any editor, if you set tab stops to be 4 spaces and the basic offset to 2, it should render correctly. there are also a couple minor indenting rule changes i made too, but maybe they don't matter too much.
see my .emacs file for the full details: https://github.com/moskewcz/mwmdots/blob/master/dot_emacs

now, going forward, there are couple ideas for improvement, with various levels of disruption:

  • i'm open to changing the basic offset to 4 at some point
  • i'm very open to standardizing on all-spaces (which could leave the basic offset at 2 or not).
  • adding some kind(s) of editor-specific documentation metadata to the project/files to at least automate getting setting right. for this, i'm not sure what is possible or makes sense, so i'm open to suggestions there.

but for now i think that, on a project-level, it's probably better to keep things how they are instead of churning things with a big whitespace change. there are other style-cleanup/standardization issues to consider as well, so maybe any big change should address more than one of them at once, and it's tricky to pick a good point in time to do them. currently, there are probably too many outstanding branches that we might actually want to merge to make a big whitespace/formatting churn a good idea.

since things can't really get worse, i don't think it matters if new code uses tabs+spaces or just spaces. just tabs isn't an option, since the basic offset is 2, and i don't think anyone proposes switch tab stops to 2 in a case like this? or do they?

as for the backstory, it's simple: long ago, i set my default basic indentation offset to 2 (as in the .emacs file), and i guess this monstrosity was the result ...

I strongly agree that the code style should be standardized. At the moment, I can confirm that the code could be rendered correctly with Vim and Emacs. But not with Sublime, IntelliJ or other GUI editors. I tried to specify the right configurations, but it didn't work.

My suggestions are:

  • I strongly agree with changing the basic offset to 4. In my opinion, having 2 spaces is less than enough for easily spot the code regions. I don't know if it makes sense to churn the code like this. But, it definitely pays off in the long run, when more developers get involved in the project.
  • I think the minimum change that we can apply is to replace all tabs with spaces so that they render correctly in every editor. I can create a new branch and apply such a modification if you want.
  • Going forward, I propose using Editorconfig. Many big projects are already using this method to keep their coding style consistent.

What are your concerns about picking the right time for applying such modifications?

i'd say, first things first, it's good that you see things working in vim and emacs.
then, i'm not clear why there would be an issue in other editors. since that's maybe the most important thing, lets deal with that first; i'd rather spend a little time tweaking editor settings (or at least trying to) prior to making any other changes.

for example, the default tab size is 4 in sublime text (and most editors) AFAIK, so i'm not sure why there would be a rendering issue. or do you mean auto-indent fails? for that, yeah, you'd certainly need to change some settings ... can you give more details on what fails and what you tried? i'm willing to do a little testing/experimentation with sublime (and/or other editors) if need be.

for the rest:

  • editorconfig: seems like a fine idea; if you create/post/PR a suitable .editorconfig file, i see no reason not to add it. if i understand correctly, then this may help allow the non-standard indent rules to work in more editors with less hastle
  • tabs-to-spaces: i think the key is that it's it's a big stop-the-world change that effects all branches, and it really shouldn't be necessary. it there were no outstanding branches (or less of them) i'd be all for it. i'm not exactly sure when a good time is, but i don't want to jump into it.
  • change-basic-offset: i think this is more subjective. in retrospect i think 4 would be better, but it's not as if 2 is unheard-of or crazy, and i'm not sure it will ever make sense to churn this project wide. i'm thinking, though, that maybe doing it at the same time as any tabs-to-space change would make sense.

OK. I addressed the issue related to tabs with Editorconfig. I created a new pull request ready for review.

yep, thanks! i dunno how i got it in my head that the 'global default' tab width was 4, but yeah, it's certainly 8, and i didn't do anything weird there (thankfully!). sorry for the confusion! i guess we can leave this issue open until we resolve at least the tabs-to-spaces global conversion (after we decide how to deal with outstanding branches, either by merging them, deciding it's okay for them to be stale and/or figuring out how to rebase/fix them post tabs-to-spaces).

OK. Sounds good.