-
-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Output standardization and formatting #864
Comments
I'd think using |
As a naive question, would it be possible to have the character be The other comment here is that we need the tables to be consistent for each implementation so that they can be properly verified. Should we create a "print table" command and put it in some sort of "aux code" directory where we can also put any code that is necessary to format output for the validator? |
It would be possible to use
vs
vs
I don't have strong feelings about any of these options, but I think that more concise output should be favored.
While it would be possible, this would require a print table function for every language which would need to be included in every implementation printing this (adding non algorithm related code to the implementations). There has already been some discussion on this topic on discord [here] (related to how lists get printed out) and the outcome was that writing a parser which accepts lists/tables from multiple languages and transforms them into a more consistent format should be done. |
I am still pushing for the |
Also note that we need to add this to the how to contribute wiki as well |
This is related to: #824
The current accepted solution to format output looks somewhat like this:
While this works fine for simple outputs, it does not really transform very well for more formatted output [like tables] as you can see here:

The table header is shifted four characters to the right, which breaks the alignment with the actual values below.
As human-readability is important for the AAA, this should be formatted in a better way, so the header conforms to the values below properly.
Now there are several ways to circumvent this, some better and more practical than others:
1. Allow
[#]
to occur at the end of the stringThis may introduce some inconsistencies, as there could be a mix of implementations using
[#]
at the end instead of the start, but it would be a pretty simple fix for these kinds of issues.2. Use some kind of zero-width unicode character
It would be possible to print out a unicode character which takes up no space, such as the zero-width space.
Now this has the big advantage of being invisible to someone just executing the implementation or looking at its source code.
However it would be very unintuitive for developers, as you need to copy paste the char in front of every string and depending on the IDE/Text editor this may be more or less difficult. It also may not be displayed properly on GitHub (which makes reviewing harder) or in terminals that do not support non ASCII chars.
Older languages and esolangs may also not have support for unicode characters.
3. Use some kind of control ASCII character
This is basically the same as above, but instead of using a unicode character, it would be possible to use C0/C1 ASCII control codes.
All the points above (unintuive for developers/reviewers, difficulties with rendering) do still apply, but nearly every language does support ASCII.
However this does not seem to be a suitable solution, as these chars often get rendered like this:

While I haven't tried all of the control characters, it looks like they all get rendered the same (which disqualifies them, as they are not zero-width in nature, which was the original goal).
4. Use smaller character to indicate non-result output
It would be possible to use
|
instead of[#]
, which would mitigate the problem as it does not shift the output as much.However it would not be that clear to the reader why it is there and it does not look as good as the original solution.
None of these ways seem ideal to me, but currently I think that the first or fourth way would be the best, as the others do have major limitations which may have unforeseen impact in the future.
As this is kind of blocking the output standardization, comments and thoughts on this would be greatly appreciated.
The text was updated successfully, but these errors were encountered: