Anonymous user
User talk:Smls: Difference between revisions
→new test cases for "extract file extension RC task: respond
(→use of the {{out}} template: reply) |
|||
| (8 intermediate revisions by 2 users not shown) | |||
Line 27:
-- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 02:39, 25 August 2016 (UTC)
: Sure, that kind of template extension is easy. Strangely enough, the <tt><nowiki>{{out}}</nowiki></tt> template already accepted an an undocumented positional parameter to replace the word "Output" with something else, as in <tt><nowiki>{{out|Return value}}</nowiki></tt>. To be safe I left that as it was, and added the new options as
:: (Regarding <big><nowiki> <tt> </nowiki></big>.) I didn't know what the <big><big><nowiki> <tt> </nowiki></big></big> tag was (supposed to be) used for. Again, somebody was changing my many texts showing what the "input" was for the program (for the <big> '''output''' </big> section to be shown as <big><big><nowiki> <tt> </nowiki></big></big>, and I just assumed that was some Rosetta Code "standard" or commonly accepted protocol. So I've been blindly using that protocol ever since. Again, I didn't want to make a point of it or question it as the bulk changes where done (as I recall) by an administrator. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:05, 25 August 2016 (UTC)
::: Both <nowiki><tt></nowiki> and <nowiki><code></nowiki> are fine for showing inline monospace text such as input data or code fragments. I prefer to use <nowiki><code></nowiki> in for data that may contain spaces, because it is styled with a subtle background color and border and thus makes it easier to see where the fragment starts and ends. --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 10:28, 27 August 2016 (UTC)
:: (Regarding my needs.) Not quite suiting my needs, but very very close. The '''comment=''' keyword adds a pre-pended double dash as well as a trailing colon. I would like another keyword (say, '''TEXT=''') which wouldn't add anything and let me specify in its entirety what text I wish to use for the cases of when a double dash and/or colon isn't quite appropriate. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:05, 25 August 2016 (UTC)
::: Done. --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 10:28, 27 August 2016 (UTC)
:::: Thank you. You epitomize what the Rosetta Code spirit and philosophy is all about. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 20:16, 27 August 2016 (UTC)
=== general feelings about (some) templates ===
Line 33 ⟶ 43:
Either the templates don't have the flexibility (or the necessary options) to support what I want (or my meaning), or the people don't know that the converting of (header or title) text into a form that they weren't intended for (or they/it may have changed the original meaning or intent). I always thought that templates were mostly used (in the templates that I normally used) for general text (for instance, headers, titles and such) and to supply a shortcut or abbreviated method to (help) express it succinctly. That is, to be used as tools, not necessary as a method to enforce conformity. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 03:12, 25 August 2016 (UTC)
=== new test cases for "extract file extension RC task ===
Since you replaced all the test cases for the Rosetta Code task '''Extract file extension''', you should probably do two additional things:
::* mark the (draft) task as being updated and that most computer language entries need to redo their programs (or, at least, update the test cases)
::* pink flag most of the entries as "needing updating" (or somesuch wording) to use the new test cases.
Technically, most of the entries are now "incorrect".
-- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:30, 31 August 2016 (UTC)
: I wouldn't call them incorrect just because they use different examples. Flagging them with the [[Template:Update|needs updating]] template for that would feel a bit harsh, no? Of course, some of the entries might be incorrect because they never read the task carefully, and instead wrote their code around the old examples (which caught fewer edge-cases implied by the task description), or even just read the page title. But that's a problem that many tasks suffer from... :) --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 06:24, 1 September 2016 (UTC)
:: Er, no. It's not they used different <u> examples</u>, but different <u> test cases</u>. That's why they are called ''test cases'', they're to be used to prove (test) that the code works correctly and the test cases are to be used for validation. There's nothing wrong about ''adding'' test cases (of the programmer's choosing, that's done all the time), but the task's test cases are to be used as part of the task's requirements. Otherwise, why have test cases? Test cases are there to have some kind of conformity among the programming entries so as to make them easier to compare. Sometimes, instead of '''test cases''', they are labeled '''examples''', which may or may not be used as part of the task's requirements. This is one reason why test cases are added to instead of replacing them (almost always while the task is still in draft status). But I understand your reluctance to flag (almost wholesale) most of the programming entries, but that's the price of changing test cases. It's an easy thing to fix (or accommodate). -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:39, 1 September 2016 (UTC)
::: I've added the "update needed" templates on this page now, because some of the solutions seemed confused by the ambiguity of the old task description anyway, so it's good to have them looked over now that the task is clearer. However, in general I disagree with your notion that the existence of test cases below the task description implies a strict requirement for solution to show those particular inputs and outputs on the page... --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 10:03, 4 September 2016 (UTC)
::: "''Otherwise, why have test cases?''" — As an aid, not an obligation:
:::* It says to programmers who want to add solutions: "Hey, here are some unit tests that can help you implement your code correctly, and to clear up any uncertainties you might have about the task requirements".
:::* Even if the task description is already super precise about all requirements, a table of test-cases helps to see at a glance what the task wants you to do, so people can decide more quickly if they even want to attempt to solve that task, and what it would involve.
:::* Not to mention that writing the test-cases helps task authors think about potential problems and edge cases, resulting in better written and more focused tasks, so it's a good thing to encourage.
::: I think those are plenty of reasons to have them, without interpreting it as a strict task requirements to actually demonstrate them. In tasks I've written, I've usually added a sentence like "Demonstrate that it passes the test cases given below" to the task description if I thought that was particularly important for the task in question (e.g. [[Brace expansion]]), and not for other tasks.
::: --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 10:03, 4 September 2016 (UTC)
::: "''Test cases are there to have some kind of conformity among the programming entries so as to make them easier to compare''" — Consider tasks like [[Compiler/lexical analyzer]] where the test-cases are very long, and produce a strictly specified output. I don't think having an exact copy of the same long <code><nowiki>{{out}}<pre>...</pre></nowiki></code> block under each solution would do anything for comparability there, it would just make it harder to browse the page. So I think it's prefectly reasonable that the solutions on that page have opted to only show ''one'' of the test-cases. In general, I think people should have some leeway as to what inputs and outputs they show. Yes, a solution should '''pass''' all the official test-cases, but it shouldn't strictly be forced to '''demonstrate''' that on the page. RosettaCode is primarily meant to compare the code that solves the task's problem, not to compare repetitive demonstrations of how to use said code.
::: --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 10:03, 4 September 2016 (UTC)
::: "''Sometimes, instead of '''test cases''', they are labeled '''examples'''''" — I would avoid the word "examples", because in many places on RosettaCode that word is already used to refer to the solutions / code entries on a task page.
::: --[[User:Smls|Smls]] ([[User talk:Smls|talk]]) 10:03, 4 September 2016 (UTC)
| |||