6 ms·

Okay, this is a really cool post, but I have a small bit of criticism - the code samples are really hard to read. I'd recommend, at minimum, adding a bit more

Okay, this is a really cool post, but I have a small bit of criticism - the code samples are really hard to read. I'd recommend, at minimum, adding a bit more whitespace so you don't end up with lines like this: if(e[i].events&(EPOLLRDHUP|EPOLLHUP))close(e[i].data.fd); Despite that minor criticism - pretty cool stuff!

en4bz 11y ago
Seems like the author is a q programmer so I'm not surprised everything is mashed together.
markpapadakis 11y ago
ClangFormat is your friend ( http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html )
- rubicks 11y ago
  I cannot second this hard enough.
kev009 11y ago
I thought it was misformatting but wow look at his code https://github.com/geocar/dash/blob/master/d.c https://github.com/geocar/dash/blob/master/d.c
- geocar 11y ago
  I've been known to write things for other people, in other ways at times[1], [2], but I'll usually start out writing this way[3], then expand it out simply to avoid that recoil that you just experienced. I actually find working this way very helpful to finding bugs and noticing redundancies, and if you're curious about techniques that improve the programmer, this method is worth some study. [1]: https://github.com/geocar/mmap/blob/master/mmap.cpp https://github.com/geocar/mmap/blob/master/mmap.cpp [2]: https://github.com/geocar/cdp-tools/blob/master/cdp-listen.c https://github.com/geocar/cdp-tools/blob/master/cdp-listen.c [3]: https://github.com/geocar/con/blob/master/con.c https://github.com/geocar/con/blob/master/con.c
  - swinglock 11y ago
    But what is that method? To my untrained eye it just looks obfuscated.
    - geocar 11y ago
      I am still working on a good explanation. Here's what I've come up with so far: I have noticed every page I scroll causes a comprehension loss of around 90%, so in reading something that is 10 pagefuls long, I might only be able to reproduce a tiny part of the program. I find not scrolling, and just moving my eyes, I rapidly absorb the program, and I find most bugs just by reading the code. This practice is absolutely impossible for me if I have to scroll very far and made difficult by scrolling at all. A lot of J/K/Q/KDB programmers do this because it is similar to APL, but I don't have an APL background. I simply do not know how to do this except to write horizontally. I learned a lot about this method by studying Arthur's code (example[1]). He frequently recommends Iverson's paper[2]. I just try to make every character count because it's still taking up space. Maybe keeping that in mind will help you read each word carefully -- maybe even out loud, if it helps. [1]: http://www.nsl.com/papers/origins.htm http://www.nsl.com/papers/origins.htm [2]: http://www.jsoftware.com/papers/tot.htm http://www.jsoftware.com/papers/tot.htm
      - kev009 11y ago
        To me it looks machine generated and it would be hard for me to mentally keep track and tick off "okay I know what the lines above do" but if it works for you and the people you work with are fine with it then good for you and I don't mean that sarcastically. The way I work and similar to most people I know but perhaps with less screen real estate.. I can fit a hundred vertical lines of one text buffer comfortably on my monitors (plural), and I can have about a dozen buffers up at the same time. If needed, that can be the same document scrolled to different areas. I also use a tool like cscope or for some languages an IDE to get additional context (type info, available operations), and that's the only way for me to quickly comprehend truly large bodies of code (kernels, etc). I don't think your strategy would work well for the projects I work on.

en4bz 11y ago

Seems like the author is a q programmer so I'm not surprised everything is mashed together.

markpapadakis 11y ago

ClangFormat is your friend ( http://clang.llvm.org/docs/ClangFormat.html http://clang.llvm.org/docs/ClangFormat.html )

rubicks 11y ago
I cannot second this hard enough.

kev009 11y ago

I thought it was misformatting but wow look at his code https://github.com/geocar/dash/blob/master/d.c https://github.com/geocar/dash/blob/master/d.c

geocar 11y ago
I've been known to write things for other people, in other ways at times[1], [2], but I'll usually start out writing this way[3], then expand it out simply to avoid that recoil that you just experienced. I actually find working this way very helpful to finding bugs and noticing redundancies, and if you're curious about techniques that improve the programmer, this method is worth some study. [1]: https://github.com/geocar/mmap/blob/master/mmap.cpp https://github.com/geocar/mmap/blob/master/mmap.cpp [2]: https://github.com/geocar/cdp-tools/blob/master/cdp-listen.c https://github.com/geocar/cdp-tools/blob/master/cdp-listen.c [3]: https://github.com/geocar/con/blob/master/con.c https://github.com/geocar/con/blob/master/con.c
- swinglock 11y ago
  But what is that method? To my untrained eye it just looks obfuscated.
  - geocar 11y ago
    I am still working on a good explanation. Here's what I've come up with so far: I have noticed every page I scroll causes a comprehension loss of around 90%, so in reading something that is 10 pagefuls long, I might only be able to reproduce a tiny part of the program. I find not scrolling, and just moving my eyes, I rapidly absorb the program, and I find most bugs just by reading the code. This practice is absolutely impossible for me if I have to scroll very far and made difficult by scrolling at all. A lot of J/K/Q/KDB programmers do this because it is similar to APL, but I don't have an APL background. I simply do not know how to do this except to write horizontally. I learned a lot about this method by studying Arthur's code (example[1]). He frequently recommends Iverson's paper[2]. I just try to make every character count because it's still taking up space. Maybe keeping that in mind will help you read each word carefully -- maybe even out loud, if it helps. [1]: http://www.nsl.com/papers/origins.htm http://www.nsl.com/papers/origins.htm [2]: http://www.jsoftware.com/papers/tot.htm http://www.jsoftware.com/papers/tot.htm
    - kev009 11y ago
      To me it looks machine generated and it would be hard for me to mentally keep track and tick off "okay I know what the lines above do" but if it works for you and the people you work with are fine with it then good for you and I don't mean that sarcastically. The way I work and similar to most people I know but perhaps with less screen real estate.. I can fit a hundred vertical lines of one text buffer comfortably on my monitors (plural), and I can have about a dozen buffers up at the same time. If needed, that can be the same document scrolled to different areas. I also use a tool like cscope or for some languages an IDE to get additional context (type info, available operations), and that's the only way for me to quickly comprehend truly large bodies of code (kernels, etc). I don't think your strategy would work well for the projects I work on.