Related
For I18n testing, I'm looking for a test string that have a good representation of all commonly used languages (supported by UTF-8) and have all the special chars of these languages that normally have issues in display.
Will use this test string to keep sure that our system process these languages correctly and have the correct font that can display all these languages correctly.
E.g. the sample text should have chars from latin languages, Far East Languages, right to left languages...
There is no clear answer to your question, as it is full of ambiguous terms, for instance "commonly used languages" or "normally have issues in display". This is highly dependent on OS, OS version, the text engine used to display the text, fonts installed. Pretty much the whole tech stack.
Sprinkling "all" in the question (all the special chars, all ... languages) make any answer useless.
You will looking at a string of tens thousands of characters. Then you have a lot of combining marks, and ligatures. Do you want to check all of those combinations too? Those might also have "issues in display"
If all you want to do is check that your application works in (most) languages, try taking some (not all) characters from each Unicode block. Might also want to avoid historical scripts (i.e. cuneiform, Egyptian hieroglyphs, etc.) the are not covered by common fonts.
In general, if you application does not corrupt the string somehow, it will render properly. And if it does not, then it is not your app at fault, it is some limitation in the underlying technology (i.e. the Windows console)
If you explain what you are trying to do, you might get a better answer.
Or you can just search for internationalization testing.
I hope this doesn't get closed due to being too broad. I know it comes down to personal preference, but there is an origin to all casing conventions and I would like to know where this one came from and a logical explanation as to why people use it.
It's where you go all like var empName;. I call that lower camel, although it's probably technically called something else. Personally, I go like var EmpName. I call that proper camel and I like it.
When I first started programming, I began with the lower camel convention. I didn't know why. I just followed the examples set by all the old guys. Variables and functions (VB) got lower camel while subs and properties got proper camel. Then, after I finally acquired a firm grasp on programming itself, I became comfortable enough to question the tactics of my mentors. It didn't make logical sense to me to use lower camel because it wasn't consistent, especially if you have a variable that consists of one word which ends up being in all lowercase. There is also no validation mechanism in place to make sure you are appropriately using lower vs. upper camel, so I asked why not just use proper camel for everything. It's consistent since all variable names are subject to proper camelization.
Having dug deeper into it, it turns out that this is a very sensitive issue to many programmers when it is brought to question. They usually answer with, "Well, it's just personal preference" or "That's just how I learned it". Upon prodding further, it usually invokes a sort of dogmatic reaction with the person as I attempt to find a logical reason behind their use of lower camel.
So anyone want to shed a little history and logic behind casing of the proper camelatory variety?
It's a combination of two things:
The convention of variables starting with lower case, to differentiate from classes or other entities which use a capital. This is also sometimes used to differentiate based on access level (private/public)
CamelCasing as a way to make multi-word names more readable without spaces (of course this is a preference over underscore, which some people use). I would guess the logic is that CamelCasing is easier/faster for some to type than word_underscores.
Whether or not it gets used is of course up to whomever is setting the coding standards that govern the code being written. Underscores vs CamelCase, lowercasevariables vs Uppercasevariables. CamelCase + lowercasevariable = camelCase
In languages like C# or VB, the standard is to start private things with lowercase and start public/protected things with uppercase. This way, just by looking at the first letter you can tell whether the thing you are messing could be used by other classes and thus any changes need more scrutiny. Also, there are tools to enforce naming conventions like this. The one created/used internally at Microsoft is called StyleCop and is available as a free download.
Historically, well named variables in C (a case-sensitive language) consisted of a single word in lower case. UPPERCASE was reserved for macros.
Then came along C++, where classes are usually CapitalizedAndCamelCased, and variables/functions consisting of several words are camelCased. (Note that C people tend to dislike camelCase, and instead write identifiers_this_way.
From there, it spread.
And, yes, probably other case-sensitive languages have had some influence.
lowerCamelCase I think has become popular because of java and javascript.
In java, it is specifically defined why, that the first word should be a verb with small letters where the remaining words start with a capital letter.
The reason why java chose lowerCamelCase I think depends on what they wanted to solve. Java was launched in 1995 as a language that would make programming easy. C/C++ that was often used was often considered difficult and too technical.
This was something java claimed to solve, more people would be able to program and the same code would work on different hardware. The code was the documentation, you didn't need to comment code, just read and everything would be great.
lowerCamelCase makes it harder to write "technical" code because it removes options to use uppercase and lowercase letters to better describe the code from a technical perspective. Java didn't want to be hard, java was the language to use where everyone could learn to program.
javascript in browsers was created in 10 days by Brendan Eich in 1995. Why javascript selected lowerCamelCase I think is because of java. It has nothing to do with java but it has "java" in its name "javascript".
I'm teaching myself Objective-C and I noticed in a lot of books and examples the use of 'k' and camel-casing in constant definition, e.g.
#define kMyConstant 0
What is the significance of the 'k'?
Is this unique to Objective-C style, or common to C in general?
Why the deviation from (what I've always thought as a best practice) K_MY_CONSTANT style?
Thanks.
It was mentioned once before in the SO question, Lower case "k" in Cocoa.
It is a general programming notation
not specific to Objective-C (i.e.
Hungarian Notation) and the "k" stands for "constant".
If you look at the Google cache of Google's guidelines for Objective-C you can see that they used to include it in their styleguide:
Constant names (#defines, enums, const local variables, etc.) should start with a lowercase k and then use mixed case to delimit words, i.e. kInvalidHandle, kWritePerm.
Though a pain to write, they are absolutely vital to keeping our code readable. The following rules describe what you should comment and where. But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names and then trying to explain them through comments.
But it has since been removed in the live version of the document. It should be noted that it goes against the the Official Coding Guidlines for Cocoa from Apple.
All caps (as in K_MY_CONSTANT) normally denotes a macro - not necessarily a constant. It's generally important for macros to stand out because they clobber all namespaces.
The 'k' convention is used (but not universally) for non-macro constants in C/C++ and probably other languages. I suspect 'k' is used because 'c' is already often used - either to denote a class name (as in CString) or that a variable is a counter.
The kMyConstant thing goes back to the very old Mac programming days (80s/90s being "very old"). This was a standard Apple used and many Mac programmers also used; this took the place of MY_CONSTANT-type definitions.
I would imagine the authors you are reading were Mac Pascal/C programmers for the old Mac Toolbox prior to being NeXT/Cocoa programmers. The Mac libraries used to be called the "Toolbox"--this was the set of APIs and libraries that turned into Carbon over time.
I still use kMyConstant sometimes; drives my old school Unix programmer colleagues nuts. :-)
I think use of a leading "k" is because all languages pronounce it as a hard consonant and thus it reminds people of the english pronunciation of "constant" :-)
No reserved words start with k so it is easier as a search target.
Alternatively, from a graphical aspect, as a leading character it provides a very clear flag in front of the rest of the name. Leading "c" is less obvious and might be used to indicate roles (such as in Hungarian notation) or classes (if in a case-insensitive language).
MY_CONSTANT is pretty well agreed as being for macro-based constants. It is sometimes important to know that a constant is defined by a macro, for example that implies it is based on literals and thus from a limited range of data types, as well as being defined at a global scope and thus (as Michael Burr pointed out) overrides any local namespaced constants.
Feel free to point me to other answers if these have already been asked!
I'm just starting F# with the new release this month. I've got some background in both OO and functional languages (Haskell and Scheme, but not OCaml/ML). A couple of questions have arisen so far from reading through the little tutorial thing that comes with the F# CTP.
1) Are mutable variables preferred over monads? If so, are monads entirely shunned in F#?
2) I'm a tad confused by the capitalization being used. In this tutorial code file, sometimes functions start with a lowercase letter, and sometimes uppercase. I know MS tends to like initial caps with functions and methods, but here it seems like there are two ways of doing it. It's not a huge deal to me, as I'm just playing around on my own time, but I am curious what the standard is.
3) I'm pretty confused about this whole combination of OO and functional styles. print_string "string" makes sense, but then here is List.map fn list (unless List is just the namespace, forgive me if so). Then here is str.Length. Anyone care to elucidate when to use what, and which is preferred?
Thanks!
Regarding mutability: F# allows you to be pragmatic. I rarely prefer a state monad to a mutable/ref, but you can do whichever you like. Monads are not shunned, but I think people tend to only use them when they're a clear-cut win (e.g. async programming).
Regarding naming: there is a tension in the fact that 'functions are values' means you might choose to name a let-bound function with a capital letter (because it's a function, and functions begin with capitals) or with a lower-case letter (because it's a let-bound value (that just happens to have an '->' in its type name)). Personally I prefer to always use upper-case names for all functions, but you'll see both styles (especially since the style of the F# library itself has been slowly evolving/standardizing over the past year or two). Underscores seem to be shunned throughout .Net, and the F# library is no longer an exception (there are a few names left that use underscores, but they stand out now like a sore thumb and will probably be changed).
Regarding function style: I am unclear what you are asking. In the case of List.map, 'List' is the name of an F# module, and 'map' is a function in that module. Member functions (e.g. str.Length) have the advantage of being commonly used throughout .Net, and provide a nice intellisense experience in the editor.
1) I wouldn't go so far as to say monads are shunned... You mentioned you have some background with Haskell - so F# workflows are what you want to look into (the term workflow maybe confusing but these only have a tiny bit to do with business process stuff). In general, sequence expressions and more generally computational expressions (a.k.a workflows) are going to be close to monads. That said mutable is pretty common though I'm not sure 'preferred' would be the way to express it. They each have a place - Personally, I started with two books -- 'Foundation of F#' - but if you're looking to dive in - go 'Expert F#' -- both are good. Honestly, I needed Foundations to help me get started.
2) In the experience I've had, the confusion is that traditional functions in .NET have a convention that really doesn't lend itself to functional programming. As such, I feel that in F# you the confusion can sometimes be when you're looking at usage of 'traditional .NET' named functions vs. elements of F# that are clearly functional... For example, in the book I mention above 'Expert F#' - they mention that you'll see let values such as List.map and Dates.Today in both camelCase and PascalCase (Pascal case being a more traditional .NET). A good rule of thumb is that if you're staying in the functional world - use more traditional functional (camelCase) naming - however if what you're making is expected to be used by other .NET languages, go with the more .NET norm (Pascal). Also note in the functional world there is a much higher tolerance for abbreviation (itr, tbl, etc... ) where as .NET in general has went away from this... So again, you'll see a varying degree of this sort of thing based on if you're calling functional elements vs. elements exposed in F# that are shared across the whole of .NET.
3) I agree that the combination of OO and function styles can be confusing. Again, I'm not sure which is preferred, beyond saying that F# (being functional) clearly styles itself in terms of the functional paradigm. However, F# is a functional language in the .NET world (notice the relative confusion of naming I mention above)... So again, it's not totally clear cut.
Hope this helps... Believe it or not, as you use F# and think of other languages that have shared concepts C++ with C (for example) - it gets easier. Personally, the naming began to make sense and the concepts worked as I started to get that I was a F# is a functional language operating on a traditional platform - made to interoperate (though I'm not sure calling the interoperation seamless would be appropriate :D)
In general monads ("workflows" in F#) are much rarer than in Haskell, firstly because mutable variables are available so it's unlikely that people would choose to use a state monad instead. Secondly there are no higher-kinded type variables, which means that you can't write code that is overloaded to work on any monad, which makes using them much less attractive.
One place that they are commonly used is in sequence expressions (which are really like list comprehensions in Haskell, but those are closely related to the list monad).
If you take over a project from someone to do simple updates do you follow their naming convention? I just received a project where the previous programmer used Hungarian Notation everywhere. Our core product has a naming standard, but we've had a lot of people do custom reporting over the years and do whatever they felt like.
I do not have time to change all of the variable names already in the code though.
I'm inclined for readablity just to continue with their naming convention.
Yes, I do. It makes it easier to follow by the people who inherit it after you. I do try and clean up the code a little to make it more readable if it's really difficult to understand.
I agree suggest that leaving the code as the author wrote it is fine as long as that code is internally consistent. If the code is difficult to follow because of inconsistency, you have a responsibility to the future maintainer (probably you) to make it clearer.
If you spend 40 hours figuring out what a function does because it uses poorly named variables, etc., you should refactor/rename for clarity/add commentary/do whatever is appropriate for the situation.
That said, if the only issue is that the mostly consistent style that the author used is different from the company standard or what you're used to, I think you're wasting your time renaming everything. Also, you may loose a source of expertise if the original author is still available for questions because he won't recognize the code anymore.
If you're not changing all the existing code to your standard, then I'd say stick with the original conventions as long as you're changing those files. Mixing two styles of code in the same file is destroying any benefit that a consistent code style would have, and the next guy would have to constantly ask himself "who wrote this function, what's it going to be called - FooBar() or fooBar()?"
This kind of thing gets even trickier when you're importing 3rd party libraries - you don't want to rewrite them, but their code style might not match yours. So in the end, you'll end up with several different naming conventions, and it's best to draw clear lines between "our code" and "their code".
Often, making a wholesale change to a codebase just to conform with the style guide is just a way to introduce new bugs with little added value.
This means that either you should:
Update the code you're working on to conform to the guideline as you work on it.
Use the conventions in the code to aide future maintenance efforts.
I'd recommend 2., but Hungarian Notation makes my eyes bleed :p.
If you are maintaining code that others wrote and that other people are going to maintain after you, you owe it to everybody involved not to make gratuitous changes. When they go into the source code control system to see what you changed, they should see what was necessary to fix the problem you were working on, and not a million diffs because you did a bunch of global searches and replaces or reformatted the code to fit your favourite brace matching convention.
Of course, if the original code really sucks, all bets are off.
Generally, yes, I'd go for convention and readability over standards in this scenario. No one likes that answer, but it's the right thing to do to keep the code maintainable long-term.
When a good programmer's reading code, he should be able to parse the variable names and keep track of several in his head -- as long as their consistent, at least within the source file. But if you break that consistency, it will likely force the programmer reading the code to suffer some cognitive dissonance, which would then make it a bit harder to keep track of. It's not a killer -- good programmers will get through it, but they'll curse your name and probably post you on TheDailyWTF.
I certainly would continue to use the same naming convention, as it'll keep the code consistent (even if it is consistently ugly) and more readable than mixing variable naming conventions. Human brains seem to be rather good at pattern recognition and you don't really want to throw the brain a curveball by gratuitously breaking said pattern.
That said, I'm anything but a few of Hungarian Notation but if that's what you've got to work with...
If the file or project is already written using a consistent style then you should try to follow that style, even if it conflicts/contradicts your existing style. One of the main goals of a code style is consistency, so if you introduce a different style in to code that is already consistent (within itself) you loose that consistency.
If the code is poorly written and requires some level of cleanup in order to understand it then cleaning up the style becomes a more relevant option, but you should only do so if absolutely necessary (especially if there are no unit tests) as you run the possiblity of introducing unexpected breaking changes.
Absolutely, yes. The one case where I don't believe it's preferable to follow the original programmer's naming convention is when the original programmer (or subsequent devs who've modified the code since then) failed to follow any consistent naming convention.
Yes. I actually wrote this up in a standards doc. I created at my current company:
Existing code supersedes all other standards and practices (whether they are industry-wide standards or those found in this document). In most cases, you should chameleon your code to match the existing code in the same files, for two reasons:
To avoid having multiple, distinct styles/patterns within a single module/file (which contradict the purpose of standards and hamper maintainability).
The effort of refactoring existing code is prone to being unnecessarily more costly (time-consuming and conducive to introduction of new bugs).
Personally whenever I take over a project that has a different variable naming scheme I tend to keep the same scheme that was being used by the previous programmer. The only thing I do different is for any new variables I add, I put an underscore before the variable name. This way I can quickly see my variables and my code without having to go into the source history and comparing versions. But when it comes to me inheriting simply unreadable code or comments I will usually go through them and clean them up as best I can without re-writing the whole thing (It has come to that). Organization is key to having extensible code!
if I can read the code, I (try) to take the same conventions
if it's not readable anyway I need to refactor and thus changing it (depending on what its like) considerable
Depends. If I'm building a new app and stealing the code from a legacy app with crap variable naming, I'll refactor once I get it into my app.
Yes..
There is litte that's more frustrating then walking into an application that has two drasticly different styles. One project I reciently worked on had two different ways of manipulating files, two different ways to implement screens, two different fundimental structures. The second coder even went so far as to make the new features part of a dll that gets called from the main code. Maintence was nightmarish and I had to learn both paradigms and hope when I was in one section I was working with the right one.
When in Rome do as the Romans do.
(Except for index variables names, e.g. "iArrayIndex++". Stop condoning that idiocy.)
I think of making a bug fix as a surgical procedure. Get in, disturb as little as possible, fix it, get out, leave as little trace of your being there as possible.
I do, but unfortunately, there where several developers before me that did not live to this rule, so I have several naming conventions to choose from.
But sometimes we get the time to set things straight so in the end, it will be nice and clean.
If the code already has a consistent style, including naming, I try to follow it. If previous programmers were not consistent, then I feel free to apply the company standard, or my personal standards if there is not any company standard.
In either case I try to mark the changes I have made by framing them with comments. I know with todays CVS systems this is often not done, but I still prefer to do it.
Unfortunately, most of the time the answer is yes. Most of the time, the code does not follow good conventions so it's hard to follow the precedent. But for readability, it's sometimes necessary to go with the flow.
However, if it's a small enough of an application that I can refactor a lot of the existing code to "smell" better, then I'll do so. Or, if this is part of a larger re-write, I'll also begin coding with the current coding standards. But this is not usually the case.
If there's a standard in the existing app, I think it's best to follow it. If there is no standard (tabs and spaces mixed, braces everywhere... oh the horror), then I do what I feel is best and generally run the existing code through a formatting tool (like Vim). I'll always keep the capitalization style, etc of the existing code if there is a coherent style.
My one exception to this rule is that I will not use hungarian notation unless someone has a gun to my head. I won't take the time to rename existing stuff, but anything I add new isn't going to have any hungarian warts on it.