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 2 years ago.
Improve this question
One of my tasks is to analyze source code. The chunks that usually takes the most time to be understood are those where the developer uses confusing terms for variables or methods, like...
myfavoritething=json.dumps(url) (what is this variable? what is the purpose? apparently the user is encoding the url for some dark purpose...)
public void getName(values, result) { ... (this was not a getter, the function has no return value, but it calculates a result from the input values)
POST /loadService (which does not load something, just returns a lot of variables)
Given that this is a quite common issue, is there a technical term for this coding-style bad habit?
Bad naming is considered to be a so called code smell. The term was first coined by Kent Beck.
In his book Refactoring: Improving the Design of Existing Code, Second Edition Martin Fowler describes patterns that help with refactoring specific flaws in code.
He also dedicates a chapter to code smells which are closely related to refactoring.
Getting back to your question:
Given that this is a quite common issue, is there a technical term for this coding-style bad habit?
As I consider this book as one of the top sources concerning this topic I would say the term that comes closest to what you are referring to is the Mysterious Name code smell as described in Fowlers book:
Mysterious Name
Puzzling over some text to understand what’s going on is a great thing if you’re reading a detective , but not when you’re reading code. We may fantasize about being International Men of Mystery, but our code needs to be mundane and clear. One of the most important parts of clear code is good names, so we put a lot of thought into naming functions, modules, variables, classes, so they clearly communicate what they do and how to use them.
Finding good names often is hard and if you are looking for some good advice in the right direction I recommend the book Clean Code by Uncle Bob. He dedicates a whole chapter (see Chapter 2 - Meaningful Names) to this topic.
There are few naming conventions to be followed by every developer to improve readability,maintainablity etc.
The above example given by you are called bad practice
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 3 years ago.
Improve this question
In a big corp, they often ask developers to fill in a matrix of what skills they have at what level. It's generally seen as a bit of a pain but is it actually useful, or another way for bureaucrats to try and reduce developers to a bunch of numbers on a spreadsheet?
Skills matrix are only partially helpful, they are good at giving you a general picture of your current "experience".
However these skills matrix does not include the most important aspect, the ability to learn.
This is the most important skill in IT in my view. And everyone learns at different speeds.
Eg. Throwing guy A into a new technology stack, and how long before he/she is productive?
Since IT/software development is a very wide field I regard skill sheets as quite useful. I used to be a Linux expert and my skill sheet reflected that. Then I shifted into iOS/Mac development and my now-employer asked me to fill out a skill sheet tuned to Mac... and I immediately noticed that I was novice in this field back then ;-) Vice versa, they were able to see whether I can fit into the company and where (in which team).
So of course they can be harmful if you lack the skills, but I think they make choices for employers easier (and I regard a big skill sheet in my CV as the most important part of the CV, even more so than the list of projects done).
The usefulness is totally dependent on what is being assessed. I work in an insurance company and this was done for all staff here. There was no category that I fit into and all the criteria were irrelevant.
I can see the benefit of assessing relevant criteria, it can identify weaknesses and target training, but those criteria need to be defined by someone who knows what you might not know.
Most of all, don't berate the bureaucrat for simplifying a complex object into a manageable set of information. As a programmer that's what you should be doing every day.
I think it is appropiate on big corps, but for small and specialized consultancies I would make a personal interview.
In big corporations if you dont fit in one place you may fit in other... in small teams I rather do personal assessment .
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 3 years ago.
Improve this question
Over the years, I've discovered that green-programmers tend to read the comments rather than the code to debug issues.
Does having one person document the other person's code (and vice-versa) with the code writer's approval increase code quality in the long term?
Is this a good idea?
aside: I'm looking for middle-ground between solo programming and pair programming in terms of budgeting.
People tend to look for the easiest solution to a problem. If there's an "human" description available, it's likely to be utilized before the reader delves into esoteric code. IOW, the comments will often be considered first, regardless of how green the programmer happens to be.
Comments should maintained as well as possible. Unfortunately, they can easily become stale (because they cannot be validated by the compiler). Therefore, they should be kept to a reasonable minimum, because, ultimately, the code itself is the only real comment that can be trusted.
As for who should write the comments, it depends at what level the comments are being written. For example, at higher levels the comments should describe the outside behavior of a module, and could be written by a larger group of people. Internally, however, the comments should explain the intent of the various chunks of code. That way, its easier for the reader to glean the mannerisms of the code. Those comments should be written by the coder.
I've found that "pair programming" works best when one person writes the code and the other one writes unit tests (working side by side so they can see what each other is doing). You can swap the roles around occasionally too.
You run a higher risk of misinterpreting algorithms if the original author does not document the code. In my opinion, the only thing more frustrating than inadequately documented code is incorrectly documented code.
You may wish to try this approach:
Perform code reviews with a developer that was not involved in the programming effort.
Have the review performed without the physical presence of the code's author. Just the reviewer, a copy of the code from source control, and written documentation.
If the reviewer can not reasonably understand the code without outside assistance, it is not adequately documented and should be given back to the author.
Repeat as necessary.
I find it works best when the helper does the broad scope thinking (i.e. What are we trying to accomplish) and the keyboard cowboy does the detail scope thinking. I don't think comments have anything to do with it.
I tend to write comment first and code immediately after that or at times or at times side by side. By the time I end up writing my comment the code becomes very clear in my mind (thanx to the fact of verbalizing my ideas while writing the comment). I don't like to comment the code which I haven't written. And whenever I come back to revise the code, first read the original comments, then think of new comments, write them and write the code side by side.
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
Robert C. Martin offers in the fist chapter of his book 'Clean Code' several definitions of 'clean code' from differen well known software experts. How do you define clean code?
Easy to understand.
Easy to modify.
Easy to test.
Works correctly (Kent Beck's suggestion - very right).
These are the things that are important to me.
Code I'm not afraid to modify.
Code that doesn't require any comments to be easily understood.
Code which reads as close to a human language as possible. I mean it on all the levels: from syntax used, naming convention and alignment all the way to algorithms used, quality of comments and complexity of distribution of code between modules.
Simplest example for naming convention:
if (filename.contains("blah"))
versus
if (S_OK == strFN.find(0, "blah"))
Part of it depends on the environment/APIs used, but most of it is of course the responsibility of the developer
Point-free Haskell code. (Not really, though.)
Code in which the different modules or classes have clearly defined contracts, is a good start.
Code which doesn't break in multiple places when you make a single, seemingly insignificant change. It is also easy to follow the control path of the program.
Reusable code is also important. So not only important is the quality of the code, but where do you put.
Example, business logic into a Controller is a useless code
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I need a simple random English sentence generator. I need to populate it with my own words, but it needs to be capable of making longer sentences that at least follow the rules of English, even if they don't make sense.
I expect there are millions of them out there, so rather than re-inventing the wheel, I'm hoping you know of a source for one, or a resource that will give me enough information that I don't have to hunt down my rusty English skills.
You're looking for an implementation of markov chains for English sentences.
A quick Google search for "markov chain sentence generator" returned:
http://www.jwz.org/dadadodo/
http://code.google.com/p/lorem-ipsum-generator/
http://kartoffelsalad.googlecode.com/svn-history/r9/trunk/lib/markov.py
I know this is an old question, but as I found it via Google I think it's worth mentioning something like Context Free Grammars in addition to Markov Chains.
My understanding of Markov Chains is that they create the "next" item probabilistically only according to what the "current" item is. Perhaps I'm mistaken, but I don't see how this would ensure that the result would follow grammatical rules.
For instance, I usually see Markov Chains suggested as a way of creating "English sounding" words. If you create a Markov chain using letters from a dataset of English words, the output would be a word that sounds English, but it wouldn't necessarily be a real word. I believe the same would be true of sentences- you can generate something which may sound ok, but it may not be a grammatically correct sentence.
Context Free Grammars (or possibly also Regular Grammars?) might be a better candidate, since they generate sentences according to a defined ruleset. And it would be easy to populate it with your own words, as the original question requests. The downside is that you need to define these rules yourself, rather than relying on a dataset. It's been a long time since I've used a grammar to generate an English sentence, so I don't remember how hard it was to get good / varied responses.
You might be able to use/modify part of the CS Paper Generator.
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
Code refactoring is the process of changing a computer program's internal structure without modifying its external behavior or existing functionality.
What is the origin of the word refactoring and why was it chosen to denote the above?
Factor has its origins in latin, the root means make or maker (hence factory, manufacture, etc). The mathematical sense of factor could possibly be interpreted as "how is this number made".
So to re-factor simply means to re-make
In Refactoring, Fowler wrote that he hasn't "succeded in pinning down the
real birth of the term Refactoring". Wikipedia mentions the term was used by Forth programmers in the 80s, Fowler also spoke about the Smalltalk community.
Math factorization's certainly helped coining this term as you don't change the value of a mathematical expression what you factorize it.
In mathematics, to factor (http://en.wikipedia.org/wiki/Factorization) is to reduce an expression to it's simplest form. Surely the same applies here?
Martin Fowler wrote about the Etymology of Refactoring. Quoting:
The foundations of what we refer to these days as refactoring comes from the Smalltalk communities. However the metaphor of factoring a program was also part of the Forth community. Bill Wake dug out the first known printed mention of the word "refactoring" in a Thinking Forth, a 1984 book by Leo Brodie. We're pretty sure that this usage didn't pass from the Forth community to the Smalltalk community, but developed independently.
According to Brian Foote, the first use of the technical word "refactoring" in print appeared in the book "Thinking Forth" in 1984.
Most probably, in context of software it was coined by Martin Fowler http://www.refactoring.com/