Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Sometimes it is difficult to invent short and accurate name for a method or variable that is clear on the first glance. Abbreviations are not recommended today. But, for instance, if we use
src and dest in function params, it is contextually clear what they mean
i often means index: for(int i=0; i<size; i++).
Are there any other abbreviations like these used in more than one language?
There are a lot of abbreviations that are common and generally understood ("args", "i18n", "HTTP", …).
I'm not sure if I get your question right, less that there is a good answer to it. A good abbreviation is short (dooh) and easily understood by the readers. So the choice of an abbreviation depends on audience; what is obvious for a particle physicist might seem far fetched for a finance analytic or a games developer.
Maybe, the misleading word is abbreviation. The choice of a good abbreviation is the same problem of naming things in general (which is known as one of the two hard things in computer science). Readability is more important than conciseness.
Conclusion: if you know your audience (and your problem domain of course), you should be able to find understandable (and not too long) namings.
[Update]
Robert Martin wrote a whole 14-page chapter on "Meaningful Names" in his book on Clean Code, which for me is a Must-Read for every serious developer.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When it comes to programming what is the difference between concept and construct for describing "patterns" used in multiple languages?
e.g. are "immutable data structures" or "pattern matching" concepts or constructs?
To start off, concepts are ways to explain something that we observe and that we try to explain. Construct is a little bit created in the opposite order. We "construct" a concept to be able to work with a situation and explain somethings that are not directly observed or deduced.
Immutable data structures is a concept since it qualifies something that is "tangible" or actually invisible with your eye but have a precise mechanic in the computer. "Pattern matching" is a concept of really specific procedures.
Now I guess that when you think about "construct" you also refer to programming "constructs" like operators (like +, -, *). In this case they are also concepts called "constructs" but shouldn't be considered to be the equivalent to "construct"/"concepts" concepts ;).
Hopefully, this helped you sort those words out.
Dan
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've recently attempted to start learning the C programming language, this question isn't specific to that one language though, or any language for that matter. I've found that I regret asking for information/best practices as early in the learning process as I have, simply because I'm receiving too much information.
As an example, I asked a question related to arrays in C:
Is defining the length of an array with a macro "excellent practice"?
What I found was, I received the answer I was looking for; but, I also received a slew of other information, that, as a beginner was absolutely over my head. I then regretted asking in the first place because I found myself worrying about things that I probably shouldn't know/care about at this stage in the learning process.
I guess what I'm asking is: do you think worrying about best practices and language caveats when I'm a beginner will be harmful to me, or is it encouraged? I find myself getting lost reading questions under the 'c' tag, of which I was trying to use to improve my knowledge, but now I'm bogged down and not making any real progress because of all the little details in comments/answers etc.
It's certainly not a bad thing, per se, as learning of advanced matters ahead of time can really help you along the road. This isn't even confined to computer science; I, for example, find myself in this position all the time when cooking a new dish or studying relatively advanced mathematics. Of course, if all the little details and super-technical stuff are stressing you out, by all means, take a step back and breathe, try and focus on the task at hand. You can always return to the more advanced topics later!
On the specific question of learning the standard practices and caveats of a given language, I personally recommend it. First of all, doing so can keep you from developing bad habits. Knowing the strengths and weaknesses of a given language are rather important, and can influence you later on. If you have one or two things you really hate about C, you can try another language in the future that addresses those issues. The sooner you acquaint yourself with such matters the sooner you can make a decision.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Programmers often wonder if the use of a certain library or programming style is overkill. They also often claim that this is the case (and they are often believed).
What does "overkill" mean in the context of programming?
"overkill" is typically used to mean deploying overly flexible and/or over-engineered solutions to solve what is ostensibly a simple and highly localized problem. The canonical example is FizzBuzz Enterprise Edition.
The term "Overkill" literarilly (if there was ever a literal use of it) refers to the action of killing something or someone, with more resources than necessary. Something like shooting a deer 50 times to make sure it dies.
In programming it applies for the same principle: making use of more resources than necessary or to find an overly complex solution to a simple problem.
Some simple examples are
for i=1 to 100
x[i]=2^z[i];
y=x;
end
Where copying the entire array x in every iteration step achieves the desired result but you could also copy it elementwise y[i]=x[i] saving you some 900 operations and is thus an overkill.
Using the OpenCV library to threshold an image is definetley possible but uses many more resources than strictly necessary and is an exagerated example of an overkill.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It's been a while I posted a question. Maybe this one belongs to Programmers or Meta, not sure.
Right now, I'm at university in my first year civil engineer. We have some programming courses where we learn Java in order to acquire the basic concepts of programming and train algorithmic thinking. Almost all my fellow students are unfamiliar with programming. I'm experienced and people do ask questions from time to time to me about their programming problems. While explaining their problem or while asking for solutions, they really often use the word "command". I noticed that, in most cases, they are referring to what we call statements. My problem is that the word command really sounds bad and is in my opinion wrong as well, in this context. So, my question is: how do I explain them not to use commands, but rather something like instructions, statements, expressions, declarations, operations? How to explain that you do not program commands?
Sentences I hear frequently:
Which commands do I need?
What does this command do?
Or am I the only one that thinks command is wrong? If so, please explain.
You could ask them to be more specific for sake of professionalism.
A car is not a truck or not a van - and there are also bikes and bicycles and other things you could drive...
I would ask for being more specific EVERY time until they change their behaviour. You can lead them to the specific expression, but they should make the step to say it from their own. Otherwise they don't make an effort, because they count on you to help them.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have more than one (non-technical) client who has been put off by the term "don't care" in a Decision Table context, even after I explain this is a technical term, and what it means. It just strikes them as a bit rude. When I search for synonyms I get results that have more to do with "apathy" than with this use of the term. (That is why I am not asking on English Language & Usage. This is also the source of the clients' reaction, I believe; it sounds too much like apathy, which is not what they expect from me as a consultant.)
Rather than fighting a silly battle I want to focus on the project. So I'd like to come up with a term that is clear to both technical & non-technical people, and is also inoffensive. Any suggestions?
So your users are going to see values and may want to select one that conveys that they don't care which value is ultimately selected?
I would suggest "No Preference".
EDIT: I might also suggest that you translate your request into layman's terms and try out the English stack exchange as suggested in the comments. Those folks might be better equipped to provide you with a plethora of answers assuming they understand your question.
Would any of these work for you?
Extraneous
Unconnected
Unrelated
Not relevant
Immaterial
Inconsequential
I have always used NA for not applicable. It seems to already be in the non-technical vocabulary.
Neutral -
Indifferent -
No Opinion -
Unaffected -
Unconcerned -
Does Not Matter