> Yes sorry my fault, it's just that I'm using linux for development with emacs
> and those lines are just too long to actually be readable (yes I'm doing 80
> chars here!).
You poor soul. You know they have invented high resolution monitors and editors
with nice UI interfaces, where one can be fairly productive, since the 1990s,
right? ;)
On a more serious note, I know some people swear by 80 chars, but I have yet to
see a study indicating that it helps with being more productive and and
introducing less bugs. If anything, I'd say it makes the amount of distracting
code higher (since your eyes have to parse more lines), and therefore reduces
the ability to concentrate on the actual substance. Then again, this is just my
subjective opinion from using a nice UI editor on a > 1600px screen. Anyhoo:
> I got used to some linux kernel development long time ago and now can't leave
> it behind as I really like it. But I can fix that no problem. I did paid
> attention to the tabs/whitespace nightmare in libusb, what did I miss? Did I
> introduce any spaces where there should be tabs? I'll review my changes again.
Since you have a Windows machine to test with, my advice would be to install
TortoiseGit (note you'll need to install msysgit first) and fetch your repo.
The diff has a very nice UI that will make it very explicit where spaces are
used in lieu of tabs, by displaying dots vs arrows. For what is worth, pretty
much all the lines you introduced in edde05c45ba7052b01fb25394d0a7267bad4c878
use space in lieu of tabs. There's also some weird stuff where you introduce
tabs in comments in d2612f119ab6dc969084e55fa122a66d998826cf.
16f11affc63fe6593036799111c8a4f86011cde4 also has spaces instead of tabs.
> BTW shouldn't there be just one code guideline for the hole project?
Some people may insist on rigid project-wide guidelines, but I personally don't
see that as a necessity, as too constraining. My take is that if you create a
new source, you get to pick your styling (as long as it's not too wild). If you
follow a source, you follow the styling used by the original author. Especially
on a project such as libusb(x), this can help with keeping people who want to
introduce a new backend happy for not having to depart from the style they are
comfortable with (even if it's something as historical as 80 chars emacs...)
I'm not going to comment on MS vs C standards, since I would only have some
very negative things to say, and that won't change the fact that, at the end of
the day, we have no choice but to deal with how restrictive MSVC is in that
respect.
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/issues/9#issuecomment-24894839
------------------------------------------------------------------------------
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
