-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi,
Am Mo den 25. Mai 2009 um 19:13 schrieb Omari Stephens: > > 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. Hmm... What is worse with forcing a unify coding style? Without the modelines every one has to set his own settings and the code get very different style. > No, my point wasn't that we should change the definition of a tab stop. Ah, sorry, I didn't understand correct. > The point was that our codebase should not contain tab characters at > all. Hmmm... With that I have no problem. I absolutely don't care if there are spaces or tabs. Vim is handling that stuff completely transparent for me. > 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. Ehem, Adding or removing a single character if the code is indented with spaces _always_ change the alignment. > Also, spaces provide sufficient granularity to move the comment away > from the code without forcing the comment to be broken over two lines. If the line is long then also space indented comments are broken to new line. > > 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. Well, I just learned from the real world. If you force programmers to much then the result is less then other way around. > 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. That is a point. The code was grown over long time. So that ends in the different solutions for the same think. However, Vlad did some unifying in the past (as I remember) and so it have to go on. I did also find some functions which are never ever called. (However, I just removed them in my local git repository.) > 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? So, geeqie is a GUI application. How should every aspect of a GUI be tested automatically? Tests might be good for command line applications or for APIs but for GUIs tests are (in my opinion) meaningless. Regards Klaus - -- Klaus Ethgen http://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <kl...@ethgen.de> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBShu4wJ+OKpjRpO3lAQr1Rgf8CV7ng6GDyk0JpgXsPTzTx2yIjLd7jujz Uz5YmITcuWwz3qloWP4o8SAagXQVKaZ138GQndFD2W85LAkYW+YQvsqkSP5ic/Ep xUnxinZ0N6lzo4xmDHFgOJhlEjooyULHwbK4kKNYq44KvN438nTCM0uieVIV+cpV 3SFh1cjTzM/r1mclW6OaDIv62AxyDTERZOqNebldiQIx7Xf+bFfkqW/a3XJF85mm vvInxhX/9EviPPkqbxXKE8WA3ANPB5KHZN9efbL8B3S6/gM81BlP8FlMPQYNfLKt RdP0E9VQ//ykzTzEj184ajt5F+zbv9+nO/uHF3yDGkX3CZe+B6mm0w== =1Dpi -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
