View source for Talk:Case-sensitivity of identifiers

== task name ==

* The task description needs to state what is needed to complete the task.
* Maybe a more descriptive title? Something like "'''Variable case sensitivity'''"?
--[[User:Paddy3118|Paddy3118]] 06:03, 7 February 2011 (UTC)

: “''Variable '''name''' case sensitivity''” is probably better still. (Mind you, hardly anyone uses case insensitive variable ''contents'' any more; some ideas are better off dying.) –[[User:Dkf|Donal Fellows]] 09:44, 7 February 2011 (UTC)
:: Yes... for better or worse, case insensitivity under unicode can be nightmarish (as can be just about anything else that wants to treat characters abstractly and consistently). --[[User:Rdm|Rdm]] 15:57, 7 February 2011 (UTC)
:I nominate "Variable identifier case sensitivity". We can of course have redirects from other candidates. --[[User:Mwn3d|Mwn3d]] 20:13, 7 February 2011 (UTC)
::Hi, identifier just doesn't roll off the tongue for me; and my sugestion isn't as good as that of Dkf, so I'd go +1 on Variable name sensitivity with a redirect for the others. --[[User:Paddy3118|Paddy3118]] 22:43, 7 February 2011 (UTC)

:How about '''Case sensitive variable names?''', including the end question mark.  --[[User:Paddy3118|Paddy3118]] 22:43, 7 February 2011 (UTC)
:: That would probably be the first page on RC with a question mark in its name. I don't know that that's a precedent I want to set. Moreover, we're producing descriptions of whether languages are case-sensitive in this area, not asking; statements, not (for the most part) questions… –[[User:Dkf|Donal Fellows]] 22:55, 7 February 2011 (UTC)

We could add a category for case sensitivity and place the task in that category.
[[User:Markhobley|Markhobley]] 15:53, 26 April 2011 (UTC)


== task clarification ==
 
I changed the example outputs in the Rosetta Code task to use pre-formatted output instead of just plain sentences &nbsp; (so that it would be plainly obvious what is expected as far as output).

However, in doing so, I observed that the period at the end of the sentence may just &nbsp; ''be a period at the end of the sentence'' &nbsp; (the old sentence, that is), &nbsp; instead of a period at the end of what's expected for the output. &nbsp; It appears that over half of the programming examples don't have the trailing period. 

As it was previously, the presence of the period was open to interpretation: &nbsp; was it a period of the sentence showing the output, or was it a period at the end of what's expected? 

If the author (or a consensus) think that the trailing period shouldn't be there, it could be removed from the example output (in the task's preamble), as that would make the computer programs less "busy" displaying the period at the end of the output. &nbsp; Computer programming is chuck full of nits. &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:08, 17 April 2016 (UTC)

-----

One thing that would be nice is to have an explicit task requirement &nbsp; (rather than &nbsp; ''we should'' ...). &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 17:08, 17 April 2016 (UTC)

:Sure, why not... --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 20:45, 17 April 2016 (UTC)