Commit b3bf02904a23d8f38d54d99ba5442faed63f23f7
1 parent
eb481eb6
TODO: cleanup
Showing
1 changed file
with
73 additions
and
10 deletions
TODO
| 1 | 10.6 | 1 | 10.6 |
| 2 | ==== | 2 | ==== |
| 3 | 3 | ||
| 4 | -* Consider doing one big commit to reformat the entire codebase using | ||
| 5 | - clang-format or a similar tool. Consider using blame.ignoreRevsFile | ||
| 6 | - or similar (or otherwise study git blame to see how to minimize the | ||
| 7 | - impact of such a change). A good time to do this would be before | ||
| 8 | - 10.6 since there is so much refactoring going on. In general, try to | ||
| 9 | - make qpdf more contributor-friendly. Look | ||
| 10 | - https://bestpractices.coreinfrastructure.org/en | 4 | +* https://github.com/qpdf/qpdf/issues/610 |
| 5 | + | ||
| 6 | +Next | ||
| 7 | +==== | ||
| 8 | + | ||
| 9 | +Priorities (could be for 10.x) | ||
| 10 | +* code formatting | ||
| 11 | +* json v2 | ||
| 12 | + | ||
| 13 | +Priorities for 11: | ||
| 14 | +* PointerHolder -> shared_ptr | ||
| 15 | +* ABI | ||
| 16 | + | ||
| 17 | +Soon: Break ground on "Document-level work" | ||
| 18 | + | ||
| 19 | +Code Formatting | ||
| 20 | +=============== | ||
| 21 | + | ||
| 22 | +It would be good to have automatic code formatting to make the code | ||
| 23 | +more consistent and to make it easier for contributors. We would do a | ||
| 24 | +big commit to bring everything up to spec. Things to keep in mind: | ||
| 25 | + | ||
| 26 | +* clang-format looks promising but is a bit of a moving target; need | ||
| 27 | + to see if its output has been stable over the past few releases | ||
| 28 | + since the first one that can produce code the way I like it | ||
| 29 | + | ||
| 30 | +* Try to match closely to what I have. At a minimum: | ||
| 31 | + | ||
| 32 | + * 80 columns | ||
| 33 | + | ||
| 34 | + * 4-space indent (no tabs) | ||
| 35 | + | ||
| 36 | + * Probably want to stick with braces on separate lines to minimize | ||
| 37 | + impact, but might consider braces on separate lines for classes | ||
| 38 | + and functions with compact braces for flow control and exception | ||
| 39 | + handling since that seems to be more popular these days | ||
| 40 | + | ||
| 41 | + * No "bin packing" -- if arguments (constructor initializers, | ||
| 42 | + function arguments, etc.) don't fit on one line, do one argument | ||
| 43 | + per line | ||
| 44 | + | ||
| 45 | + * With the exception of short lambdas, no block constructs can be | ||
| 46 | + collapsed to a single line. | ||
| 47 | + | ||
| 48 | + * Braces are mandatory for all control constructs (no if, while, | ||
| 49 | + etc. without braces) | ||
| 50 | + | ||
| 51 | + * Space after control constructs | ||
| 52 | + | ||
| 53 | +* Try to get emacs c-style to match as closely as possible | ||
| 54 | + | ||
| 55 | +* Consider blame.ignoreRevsFile if it seems to help | ||
| 56 | + | ||
| 57 | +* See also https://bestpractices.coreinfrastructure.org/en | ||
| 58 | + | ||
| 59 | +* QTC::TC first two arguments have to be lexically on one line. If the | ||
| 60 | + code formatter breaks this, some QTC calls may have to be surrounded by | ||
| 61 | + | ||
| 62 | + // clang-format off | ||
| 63 | + // clang-format on | ||
| 64 | + | ||
| 65 | + or qtest may have to be made more flexible unless the formatter has | ||
| 66 | + some rules about some places where lines shouldn't be broken. | ||
| 67 | + | ||
| 68 | +* auto_* files from generate_auto_job should be exempt from | ||
| 69 | + formatting. | ||
| 70 | + | ||
| 71 | +Ideally it should be possible to run formatting in CI so that pull | ||
| 72 | +requests have to be properly formatting, but if not, there needs to be | ||
| 73 | +a `make format` similar to `make spell` that I could apply after | ||
| 74 | +merging contributions and from time to time. | ||
| 75 | + | ||
| 76 | +A .clang-format file can be created at the top of the repository. | ||
| 11 | 77 | ||
| 12 | Output JSON v2 | 78 | Output JSON v2 |
| 13 | ============== | 79 | ============== |
| @@ -319,7 +385,6 @@ Other notes: | @@ -319,7 +385,6 @@ Other notes: | ||
| 319 | way that works for the qpdf/qpdf repository as well since they are | 385 | way that works for the qpdf/qpdf repository as well since they are |
| 320 | very similar. | 386 | very similar. |
| 321 | 387 | ||
| 322 | - | ||
| 323 | PointerHolder to std::shared_ptr | 388 | PointerHolder to std::shared_ptr |
| 324 | ================================ | 389 | ================================ |
| 325 | 390 | ||
| @@ -353,7 +418,6 @@ auto x = std::shared_ptr(new T[5], std::default_delete<T[]>()) | @@ -353,7 +418,6 @@ auto x = std::shared_ptr(new T[5], std::default_delete<T[]>()) | ||
| 353 | vs. | 418 | vs. |
| 354 | auto x = std::make_unique<T[]>(5) | 419 | auto x = std::make_unique<T[]>(5) |
| 355 | 420 | ||
| 356 | - | ||
| 357 | PointerHolder in public API: | 421 | PointerHolder in public API: |
| 358 | 422 | ||
| 359 | QUtil::read_file_into_memory( | 423 | QUtil::read_file_into_memory( |
| @@ -401,7 +465,6 @@ At that point, we're in a good state to make that compatibility | @@ -401,7 +465,6 @@ At that point, we're in a good state to make that compatibility | ||
| 401 | basically works. Then we can proceed to remove PointerHolder from | 465 | basically works. Then we can proceed to remove PointerHolder from |
| 402 | everything else. | 466 | everything else. |
| 403 | 467 | ||
| 404 | - | ||
| 405 | ABI Changes | 468 | ABI Changes |
| 406 | =========== | 469 | =========== |
| 407 | 470 |