I tried to find literature on this but couldn't seem to find any. Examples in PEP8 do not include digits (I'm using Python, but this question should be language agnostic).
In snake_case, I would write variable1, variable2, and this is fine to me as the number stand out.
However, in ALL_CAPS, I instinctively write VARIABLE_1, VARIABLE_2 instead of VARIABLE1, VARIABLE2, I suppose because it feels like the digits blend into the words without an underscore separating them. For a more real example see NUM2WORDS v NUM_2_WORDS, the latter seems far clearer, at least to me.
Is this "wrong" (as far as the definition of that word can stretch)? What is the prevailing style and why?
In prose (ordinary writing) you would write "variable 1" not "variable1", so for sake of consistency I think you should add an underscore when snake case is used, i.e. variable_1.
Related
Recently, i've wanted to use capitalize() function.
When I did so, a warning occured:
'capitalize(): String' is deprecated. Use replaceFirstChar instead.
The suggested replaceFirstChar feels quite long and complicated:
input.replaceFirstChar { if (it.isLowerCase()) it.titlecase(Locale.getDefault()) else it.toString() }
Although everything works fine with capitalize(), i've been just wondering what the reason for deprecated warning is, if there's any problem with it and how can i solve this.
There is no problem with the code per se. The "issue" is what capitalize means for all of the possible languages/characters/platforms/locales.
The doc even says why it is deprecated.
The title case of a character is USUALLY the same as its upper case
with several exceptions. The particular list of characters with the
special title case form depends on the underlying platform.
If you follow all of the reasoning why it is deprecated you reach isTitleCase where you will have an example of characters in languages where the character should not be "upper cased".
Capitalization is writing a word with its first letter as a capital letter (uppercase
letter) and the remaining letters in lower case, in writing systems
with a case distinction.
There are a few good examples and explanations for different languages on Letter case Wiki
e.g.
The German letter "ß" formerly existed only in lower case.
I saw this question and it got me wondering.
Ignoring the fact that pretty much all languages have to be backwards compatible, is there any reason we cannot use operators as both keywords and functions, depending on if it's immediately followed by a parenthesis? Would it make the grammar harder?
I'm thinking mostly of python, but also C-like languages.
Perl does something very similar to this, and the results are sometimes surprising. You'll find warnings about this in many Perl texts; for example, this one comes from the standard distributed Perl documentation (man perlfunc):
Any function in the list below may be used either with or without parentheses around its arguments. (The syntax descriptions omit the parentheses.) If you use parentheses, the simple but occasionally surprising rule is this: It looks like a function, therefore it is a function, and precedence doesn't matter. Otherwise it's a list operator or unary operator, and precedence does matter. Whitespace between the function and left parenthesis doesn't count, so sometimes you need to be careful:
print 1+2+4; # Prints 7.
print(1+2) + 4; # Prints 3.
print (1+2)+4; # Also prints 3!
print +(1+2)+4; # Prints 7.
print ((1+2)+4); # Prints 7.
An even more surprising case, which often bites newcomers:
print
(a % 7 == 0 || a % 7 == 1) ? "good" : "bad";
will print 0 or 1.
In short, it depends on your theory of parsing. Many people believe that parsing should be precise and predictable, even when that results in surprising parses (as in the Python example in the linked question, or even more famously, C++'s most vexing parse). Others lean towards Perl's "Do What I Mean" philosophy, even though the result -- as above -- is sometimes rather different from what the programmer actually meant.
C, C++ and Python all tend towards the "precise and predictable" philosophy, and they are unlikely to change now.
Depending on the language, not() is not defined. If not() is not defined in some language, you can not use it. Why not() is not defined in some language? Because creator of that language probably had not need this type of language construction. Because it is better to let things be simpler.
Why in various programming documentation for functions do they have square brackets around parameters, but they are ordered such that the later parameters seem to be subsets of the first? Or if the brackets in that language delineate arrays it's as if the second parameter is supposed to be inside of the array of the first, but often the parameters are not even supposed to be arrays, and also they have commas in weird places.
I've seen this style all over the place and tried to find some place where it is written down why they do this. Maybe someone just arbitrarily decided on that and other programmers thought, "oh that looks cool, I'll try that in writing my own documentation.."
Or maybe there is some big book of rules for how to make programming docs? If so I'd like to know about it.
Here is an example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/slice
if you go to the link in the blue box near the top of the page right bellow the h2? heading "syntax" it says this: arr.slice([begin[, end]]) meaning that the first parameter is begin, and the next parameter is end, for the slice method. When you first see something like this it looks like the brackets and commas are randomly placed.. but they do it all over the place and the same way. There must be some method to the madness!
Brackets around a parameter name indicate that it is an optional parameter. E.g. you can call the slice method without an end parameter. This is just a general rule of language syntax documentation, square brackets indicate optional words/tokens.
I know you can get a character vector of all numbers with ∊⍕¨⍳10, but is there a platform independent idiom for getting a vector of all alphabetical characters, aside from manually typing 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'? I know that I can do ⎕AV[(⍳26)+(⎕AV⍳'a')-1] to get all lowercase characters (and uppercase by changing the 'a' to 'A') in Dyalog APL, but I presume the system variable ⎕AV isn't available in other environments.
Not really.
In Dyalog APL, what I generally do is use ⎕A for the uppercase characters and ⎕UCS 96+⍳26 for the lowercase characters. (And ⎕A,⎕UCS 96+⍳26 for the whole alphabet.)
⎕AV is usually present, but its contents are not standard. (For example, NARS2000's ⎕AV is different from Dyalog's.) By the way, in Dyalog ⎕AV is considered deprecated in favour of ⎕UCS. Any APL that implements ⎕UCS will do it the same way, because Unicode is a set standard.
If you want a guaranteed implementation-independent, readable way to define the alphabet I would indeed recommend to just store abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ in your workspace.
However, I would not recommend trying to write implementation-independent APL code to begin with. APL dialects are rather divergent, so this is decidedly nontrivial (if possible at all for complex code), and will be difficult to maintain.
Even though Quad names (⎕xxx) are usually case insensitive, MicroAPL distinguishes between ⎕A and ⎕a, so ⎕a,⎕A gives 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'.
Yes, in the latest versions*, write ⎕A,819⌶⎕A, for ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.
Try it online!
Documentation.
* Latest builds of 14.1, and all versions of 15.0 and up.
We are currently implementing a Zend Framework Project, that needs to be translated in 6 different languages. We already have a pretty sophisticated translation system, based on Zend_Translate, which also handles variables in translation keys.
Our project has a new Turkish translator, and we are facing a new issue: Grammar, especially Turkish one. I noticed that this problem might be evident in every translation system and in most languages, so I posted a question here.
Question: Any ideas how to handle translations like:
Key: I have a[n] {fruit}
Variables: apple, banana
Result: I have an apple. I have a banana.
Key: Stimme für {user}[s] Einsendung
Variables: Paul, Markus
Result: Stimme für Pauls Einsendung,
Result: Stimme für Markus Einsendung
Anybody has a solution or idea for this? My only guess would be to avoid this by not using translations where these issues occur.
How do other platforms handle this?
Of course the translation system has no idea which type of word it is placing where in which type of Sentence. It only does some string replacements...
PS: Turkish is even more complicated:
For example, on a profile page, we have "Annie's Network". This should translate as "Annie'nin Aği".
If the first name ends in a vowel, the suffix will start with an n and look like "Annie'nin"
If the first name ends in a consonant, it will not have the first n, and look like "Kris'in"
If the last vowel is an a or ı, it will look like "Dan'ın"; or Seyma'nın"
If the last vowel is an o or u, it will look like "Davud'un"; or "Burcu'nun"
If the last vowel is an e or i, it will look like "Erin'in"; or "Efe'nin"
If the last vowel is an ö or ü, it will look like "Göz'ün'; or "Iminönü'nün"
If the last letter is a k (like the name "Basak"), it will look like "Basağın"; or "Eriğin"
It is actually very hard problem, as grammar rules are different even among languages from the same family. I don't think you could easily do anything for let's say Slavic languages...
However, if you want to solve this problem (because this is extra challenging) and you are looking for creative (cross inspiring) ways to do that, you might want to look into something called ChoiceFormat (example would be one from ICU Project) or you can look up GNU Gettext's solution for plural forms problem.
ICU (mentioned above) has a SelectFormat http://site.icu-project.org/design/formatting/select that may be of help- it's like a choice format but with arbitrary keywords. Also, it does have a PluralFormat which already has rules for many language's plural rules.