/* ME: ...so it parses a string? Doesn't pretty
* much every parser? Also, no prefix again. */
void
strparse(void) {
* Lack of overall project structure. Maybe some comments here would clear things up, but even some groupings like this would be nice:
/*************************
* X11 CALLBACKS GO HERE
*************************/
* No tests. I think reasonable people can disagree about how testing should happen, but I'm a hard sell if you tell me your code needs absolutely no automated testing. If a new dev wants to commit a patch, how does she know her code works?
* Here's a scenario broached by the README:
One goal of st is to only support what is really
needed. When you encounter a sequence which you
really need, implement it.
...my problem is that there are no instructions here nor comments in the code about how start doing that ('see commit X in the repo' would even work). Again, I would hope that a dev-oriented tool like this (editing config.mk is in the installation instructions) would be a bit more friendly to developers who are stepping into the project for the first time.
My concern is that the code might suck less than xterm (I'm not familiar with that code-base), but I'm not sure "less cruft" is a good enough reason for me to want to get involved with (or even use) a project. Of course, I'm willing for the people of suckless.org to prove me wrong in my assessment.
strparse makes sense if you read the code linearly, since they also have csiparse, and deal with STREscape and CSIEscape, respectively. If you did need to add an escape sequence, it would take less than a minute to find where to add it.
While I wouldn't call it a paragon of clarity, it basically follows the same style and organization as older Unix tools. In such cases, I find starting from main() and jumping around with ctags a useful strategy (after reading the globals and type definitions).
Oh, and I strongly agree about tests. Especially escape sequence parsing could benefit from fuzzing or other property-based testing approaches.
...it basically follows the same style and organization
as older Unix tools. In such cases, I find starting from
main() and jumping around with ctags a useful strategy
(after reading the globals and type definitions).
Oh, I know it's the same style and organization as older Unix tools. And it's the same style and organization as large one-off perl scripts. It would be a shame to replace old cruft with new stuff that doesn't the leverage lessons learned in software engineering over the last 40 years or so.
* ignoring C best practices:
* barely any comments * Lack of overall project structure. Maybe some comments here would clear things up, but even some groupings like this would be nice: * No tests. I think reasonable people can disagree about how testing should happen, but I'm a hard sell if you tell me your code needs absolutely no automated testing. If a new dev wants to commit a patch, how does she know her code works?* Here's a scenario broached by the README:
...my problem is that there are no instructions here nor comments in the code about how start doing that ('see commit X in the repo' would even work). Again, I would hope that a dev-oriented tool like this (editing config.mk is in the installation instructions) would be a bit more friendly to developers who are stepping into the project for the first time.My concern is that the code might suck less than xterm (I'm not familiar with that code-base), but I'm not sure "less cruft" is a good enough reason for me to want to get involved with (or even use) a project. Of course, I'm willing for the people of suckless.org to prove me wrong in my assessment.