Klaus Ethgen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, > > Am Mo den 25. Mai 2009 um 0:25 schrieb Omari Stephens: >> I found myself with some free time this weekend, > > Lucky dear. ;-) > >> #2) We need to get rid of tabs as an acceptable form of whitespace >> Yes, switching will be painful. But ever since people started telling their >> editors to use 4-character or 2-character tabstops, tabs have become more >> pain >> than they're worth. This is especially evident when people try to align >> code or >> comments written with one setting, and other people try to view them with an >> editor set to some different setting. This is clearly visible in [1], and >> it's >> ugly and hard to read (see lines 369, 375, and 380 for one example; >> 383???387 for >> another). > > I don't see the point. I myself prefer 3 spaces indenting. But I leave > the tap stops at 8 tabs which gets replaced automatically by my $EDITOR. > > At least for the editor Vim there should be a modeline in every source > file which forces the coding style to the correct one. The same feature > might be available for other editors too. I hadn't noticed that the VIM modelines were present. They seem to dictate 8-space tabstops (which is how my editor is set), which simply goes to demonstrate that the problem is worse than I originally thought.
>> As a replacement, I would suggest using 4 spaces per level of indentation. >> I >> find that 4 spaces is wide enough that it's easy to visually track over long >> vertical distances (2 spaces is not), but is also not so wide so as to make >> it >> painful to write code 4-levels-deep (which is one problem with 8-space tabs). > > As I mention above I like to have 3 space indenting. That is enough but > not to much. But even with 3 space indent I always have 8 space tab > stop. I do not think that we should force to change this 8 space tabs. > That would be difficult viewing the source by less or printing it. No, my point wasn't that we should change the definition of a tab stop. The point was that our codebase should not contain tab characters at all. At the very least, though, I think that trying to indent comments (that occur on the same line as some code) with tabs is a losing proposition — adding or removing a single character can (and often does) throw the alignment way out of whack. Also, spaces provide sufficient granularity to move the comment away from the code without forcing the comment to be broken over two lines. ::snip? SNIP!:: >> There are clearly tons of options here, and I think "use your judgment" will >> have to be a big part of it. However, we still need some ground rules. >> Look at >> [1] again. The comments are _all over the place_. Switching to spaces (see >> #2 >> above) will make this much more readable, but having some sort of concrete >> suggestion would be a good thing. > > It would be nice to have beautified code. But that doesn't happens > unless we prove that as a checkin filter. However. I prefer to _have_ > comments than that they are left out cause of lazy to format them > proper. (And programmers _are_ lazy. ;-) True. However, consistently-formatted and -commented code is a _huge_ help as far as getting acquainted with a codebase; it can easily make the difference between gaining new contributors and stumping people who move on because they can't figure it out. To put that point clearly, yes, comments are good. The codebase doesn't have nearly enough comments for me to suggest that their value outweighs the value of having them formatted consistently. Also, don't tell me it's a pain to add or remove some whitespace so that the comments line up; come on. As for my personal experience, my employer has fairly strict coding guidelines, which include that functions/methods MUST be commented to be checked in. This dramatically reduced my time to get acquainted with the code, because I could read through it, read what each method did and was intended to do, and figure stuff out in my head. To reiterate, I knew where new code was supposed to go because the comments dictated what the different methods were intended to do. By contrast, working through geeqie's new-window creation process, I saw a bunch of different ways I could try to fix the color-management thing. The problem was that it was practically impossible to tell which was correct or not — I had no way to figure out what a function was _intended_ to do, and the code was often convoluted enough that I had to run it through gdb to figure out what it actually did. In many cases, there were different codepaths that appeared to do pretty much the same thing, and it was practically impossible to figure out why the codepaths were different, or what I might break if I tried to merge them. So, this leads to another thing: we need tests. We absolutely need tests. Note that what "test" actually means is "a specification of behavior." Otherwise, it's difficult or impossible to know whether a potential change will break some other behavior, or modularity, or abstraction barrier. And what better type of specification than one that can also check and enforce that the code is still in-spec? --xsdg ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
