|
From: Juhász P. <pet...@gm...> - 2014-03-07 21:53:28
|
On Fri, 2014-03-07 at 11:40 -0800, Ethan A Merritt wrote: > On Friday, 07 March, 2014 20:28:53 Juhász Péter wrote: > > There is one more point I'd like to raise: > > there have been much talk about new features and small, incompatible > > changes, but perhaps a new major release would be a good time to look at > > the state of the program from a different perspective: find and fix > > longstanding bugs, go through the featureset and check for > > inconsistencies and irregularities, check code quality and refactor > > where needed. > > That's pretty vague. Do you have specific things in mind? > The patch for translated messages offers a good case study. The functionality would be good to have, but the changes associated with it look like unfeasibly large because the code is not organized right for it. Strings that are part of user messages are all over the place, spread over several files, embedded in ad-hoc parsing code. If they were already concentrated, it would be easier to localize them. As for areas for refactoring: there is datafile.c with its convoluted code paths that nobody dares to touch in fear of breaking it; much of the axis-related code, too complicated and full of hard-coded special cases like the log-scaling you've mentioned; then there is some duplicate code in the 2d and 3d plotting code paths... There are too many terminal types, many of them ancient, not really used and tested anymore, each supporting different features, having different defaults. Against all these there is the time-honored principle of not trying to fix that ain't broken. That and the fact that all contributors to the project are volunteers, sacrificing their own free time. I can accept a decision that attacking any of the problems outlined above is not feasible given the constraints of time and manpower, I just wanted to start a discussion on them, to get these issues out in the open. Peter |