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
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 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 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.
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 4 years ago.
Improve this question
I'm trying to do some analysis and when writing down a list of functionalities I realized I'm a bit fuzzy on the notion.
What can you consider as functionalities like, say, on this Stackoverflow page? Also, to distinguish between the two, how would you define an operation?
My understanding is that the former is something vague, synonymous with a feature or use-case, defining a distinct need/requirement without going into details. Whereas, the latter is something basic, perhaps a subset of the former, but I wouldn't say it's atomic since an operation could be composed of other operations.
Edit: Here's a link on the subject: http://forum.wordreference.com/showthread.php?t=17873
P.S: Functionality might not be the correct expression in English. If so, please confirm this. "Fonctionalité" is often used with respect to software in the French language.
I'm looking forward to other answers, though I suspect this is more of a language issue than that there are universally defined meanings to these two terms, functionality and operation. Therefore, the following is to be taken as just my personal opinion.
To me, functionality (in the sense that you seem to be talking of, as opposed to the meaning of the word in the linked-to forum discussion) refers to use cases, that is, to something that your product/system offers for achieving some goal. It's not a specific action you can perform, but rather an abstract statement of what a system allows you to do. Related terms are feature, or facility. (Btw. I think for this meaning of the word "functionality", feature would be more appropriate.) For example, you could say:
"This site offers search functionality / has a search feature for finding previously published articles."
An operation (or action?) on the other hand is far more specific. It's not something your system/product offers, but something that is actually done with it. You would probably be talking about operations when you can say exactly how it is to be performed, e.g.:
"A search operation is performed by first entering keywords in this-and-that input field, followed by a click on the 'Go' button."
If you take these two together, you could probably say that "functionality" is an abstract category for a number of concrete "operations" that go towards achieving the same general goal.
But I admit I cannot define the two terms more precisely, either; esp. with regards to choosing the right "granularity" for defining specific functionalties or features.
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 7 years ago.
Improve this question
Example: 2 of our top 3 users are working in almost equivalent projects (I don't know them in depth, maybe I'm wrong):
Marc Gravell's Protobuf-Net
Jon Skeet's DotNet-Protobuf
Jokes about Jon Skeet apart, and dreaming with an prideless ideal world (sorry guys, I am not accusing you of being arrogant, is a fact that every programmer must defend his own code), wouldn't it be a great opportunity to join efforts?
I am not saying that the community should decide what an individual must do, I just want you to raise pro and cons of merging projects, and what projects must have to be subject of such analysis.
Starting a new project without a thorough research of the available solutions and without taking into serious consideration the possibility to join an existing project, is something that the community should frown upon more emphatically. Maybe a programmer's education should include some discussion on the cost of effort duplication.
Having said that, experimenting with different approaches to solve the same problem is healthy, and once a programmer has some toy code, we should thank him for making it available to the public regardless of the existence of similar projects.
I think that the authors should seriously consider a merge if:
one design has proven clearly superior to the other
one community is being more active than the other
both projects share the same ideas on future directions
the work required to merge the two codebases is feasible
Merging should happen when it is overall beneficial. For example, if either or both of the projects:
Are too weak to survive on their own (not enough active development to keep up with technology changes); or...
Could provide good synergy through overlapping (i.e. not fully identical) functionalities.
However, there isn't anything wrong with having two strong projects that both do the same thing - it can help to encourage innovation as they try to be better than each other.
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
You could very well leave out "as a technical lead", but I think it puts the situation into context. I'm a technical lead, we're building a new app, and I have an idea of the language I would like the team to use. If one or more want to use a different language (out of personal preference), is it appropriate for me to reject it (out of personal preference). It really does have to do with coding style, and nothing much else.
I don't think you need to "reject it out of preference". You need to determine the root cause for why it isn't a preference of yours and reject it for those reasons.
If you can rationalize your decision with those reasons, you'll sound more credible to your reports as well as having good documentable reasons for why you did or did not use a given technology. For projects I've worked on, these "reasons" are usually a requirement.
You are responsible for the technical success of the project. Your reports are not. So yes.
By priorities
Choose one best fit for the task
Choose one you and your people are most fluent in
Choose one that is already used in your codebase
"It's good to be the king"
I dont't think it would be right to dismiss the other languages because you prefer another unless it really does not make any difference which language that you use.
First look at the other language objectivly and see what the merits for that language are. You should reject a language because it is not the right tool for the job but not because you do not like it.
/Flamebait On
If it's VisualBasic, then yes......
/Flamebait Off
HMcG
It's never a good idea to reject something just because you aren't familiar with it or have a bias against it. There are good reasons for not using a language/technology and these should be the basis for your decisions. Normally, these reasons include:
Lack of support for the language in
the team, support team. This is a
biggy - if your team delivers an
application that can't be supported
because nobody else knows the
technology then you shouldn't do it.
The technology is unproven. You
shouldn't use a live project to
prove a technology just because a
developer wants to improve their
resume. There are too many pitfalls
here, and I've seen so many projects
fail spectacularly just because the
developers were all looking at the
wrong technology.
Licensing. Just
because there's a new language out,
doesn't mean that you can afford to
use it. The language may require
certain libraries/IDEs that you
don't have and would have to invest
in.
You can't discount that you will be a more effective leader leading a team using tools and techniques you are familiar with and believe in. But, if you are forcing the team to use something that maybe isn't the best fit for the project, you will not gain their respect and ultimately be very ineffective.
Which language are you talking about?
It should be the team's decision.