It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Code clones, also known as Duplicate code is often considered harmful to the system quality.
I'm wondering whether these duplicate code could be seen in standard APIs or other mature tools.
If it is indeed the case, then which language(such like C,Java,Python,common lisp etc.) do you think should introduce code clone practice with a higher probability?
Code cloning is extremely common no matter what programming language is used, yes, even in C, Python and Java.
People do it because it makes them efficient in the short term; they're doing code reuse. Its arguably bad, because it causes group inefficiencies in the long term: clones reuse code bugs and assumptions, and when those are discovered and need to be fixed, all the code clones need to be fixed, and the programmer doing the fixing doesn't know where the clones are, or even if there are any.
I don't think clones are bad, because of the code reuse effect. I think what is bad is not managing them.
To help with the latter problem, I build clone detectors (see our CloneDR) that automatically find exact and near-miss duplicated code, using the structure of the programming language to guide the search. CloneDR works for a wide variety of programming languages (including OP's set).
In any software system of 100K SLOC or more, at least 10% of the code is cloned. (OK, OK, Sun's JDK is built by an exceptionally good team, they have only about 9.5%). It tends to be worse in older conventional applications; I suspect because the programmers clone more code out of self defense.
(I have seen applications in which the clones comprise 50%+ of code, yes, those programs tend be awful for many reasons, not just cloning).
You can see clone reports at the link for applications in several langauges, look at the statistics, and see what the clones look like.
All code is the same, regardless of who writes it. Any API that you cite was written by human beings, who made decisions along the way. I haven't seen the perfect API yet - all of them get to redo things in hindsight.
Cloning code flies in the face of DRY, so of course it's recommended that you not do it. It's harmful because more code means more bugs, and duplication means you'll have to remember to fix them in all the clones.
But every rule has its exceptions. I'm sure everyone can think of a circumstance in which they did something that "best practices" and dogma would say they shouldn't, but they did it anyway. Time and other constraints don't always allow you to be perfect.
Suggesting that permission needs to be granted to allow such a thing is ludicrous to me. Be as DRY as you can. If you end up violating it, understand why you did it and remember to go back and fix it if you get a chance.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
Other than the speed, what are the advantages/differences to each? i.e. can assembly do more than c/c++, or what advantages does java offer that python does not (excluding the fact that java is platform independent)?
A higher level programming language usually means that the programmer can be more abstract, and generally do less work, at the cost of fine control.
For example, programming a GUI in assembly would suicidal. On the other hand, machine code is necessary when you want to take advantage of device-dependent optimizations and features. I guess you can define that low-level languages as those that are used for low-level tasks, e.g. drivers, operating systems, and parsers. Of course, the definitions are always rather fuzzy.
Pretty broad question there, and I cannot answer for the specifics between python and java, but in general here's my thoughts... keep in mind, this is nearly a philosophical question (perhaps even best suited for the Programmers stackexchange group) so there's no god-like answer. here goes:
with low level languages (the closer you get to bit flipping), you tend to be closer to the system hardware and core operating system... resources are more explicitly manipulable... this makes for efficient programming in that you can streamline your logic, skim off the bundled crap you don't need and develop the perfect piece of code... the consequence is that it's usually harder to think in and thus code in.
higher level languages provide abstraction, moving the developer away from the worries of 1s and 0s to focus on more complex requirements of a system. they allow us to think about things closer to the semantics of human communication and thought. they also allow us to share work cross-platform sometimes when programmers work in high level languages that compile to common run-times. there are numerous other reasons, but you get the gist.
ultimately I look at low level languages as something to use to "make the best tool", and high level languages to "make the best use of the best tools"
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I use the term all the time... but I was just sort of thinking that I don't really have a solid denotational sense behind the term (or at least the term in the sense I want to discuss here). I'm interested in the sense of the word related to code, not the anthropomorphic idea. I'm also not interested here in the sense of the word related to intentional malicious computing (i.e. a hack to unlock secret powers in a game). What I want to explore is what it means to 'hack' in terms of writing software to solve a problem
wikipedia's def of 'hack' to me is a bit vague, but a decent starting point. It considers a hack
can refer to a solution or method which functions correctly but which is "ugly" in its concepion
works outside the accepted structures and norms of the environment
is not easily extendable or maintainable
can be slang for "copy", "imitation" or "rip-off."
These traits of a hack conform to my usage of the word--when applied to code it is always a term of derision. To my mind, a hack
Is likely to be difficult to maintain & hard to understand in the context of the rest of the code.
Is likely to cause failure of the app.
tends to indicate a poor understanding by the coder either of the problem space, usage of the language or both
tends to be the byproduct of aggressive schedules
suggests potential changes in requirements that have not been fully incorporated into the architecture of the solution (requiring an 'inorganic' workaround).
smells
all bad, bad, bad. To me, a hack in this sense is always negative, indicating either lack of time, incompetence, or sloth on the part of the developer, though a decent percentage of hacks must be written to compensate for ill-conceived designs or systems that have gained requirements which their original design cannot handle 'organically'.
I don't think I've really captured it totally though--it's like pornography a bit: I can't really define it, but I know it when I see it. So I ask you: what does it mean to 'hack' when you are trying to solve a problem in software?
I've always preferred Paul Graham's definition:
To add to the confusion, the noun "hack" also has two senses. It can be either a compliment or an insult. It's called a hack when you do something in an ugly way. But when you do something so clever that you somehow beat the system, that's also called a hack. The word is used more often in the former than the latter sense, probably because ugly solutions are more common than brilliant ones.
From the Jargon File, the glossary of hacker slang:
The Meaning of ‘Hack’
“The word hack doesn't really have 69 different meanings”, according to MIT hacker Phil Agre. “In fact, hack has only one meaning, an extremely subtle and profound one which defies articulation. Which connotation is implied by a given use of the word depends in similarly profound ways on the context. Similar remarks apply to a couple of other hacker words, most notably random.”
Hacking might be characterized as ‘an appropriate application of ingenuity’. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it.
An important secondary meaning of hack is ‘a creative practical joke’. This kind of hack is easier to explain to non-hackers than the programming kind.
When I think of "hack", I think of it as being a non-expected workaround to solve a problem, not necessarily a bad thing. Creative, innovative, and well-placed. "Hack" can apply to more than just computers, though I seldom hear it used that way.
Too often "hack" simply means: "Not the way I would do it."
This topic will turn into something like a question about Love. Everyone's gonna have their own definition. The best way to know the proper (default) definition is in the dictionary
It's when you've stepped out of the idiomatic, natural, sensible and (sometimes) supported ways of doing something in a given language/framework/etc.
Sometimes that's a stroke of genius, usually it's an act of idiocy, occasionally it's one disguised as the other, and on rare occasions it's both.
(Incidentally, the judge who coined that statement about pornography you quote later retracted in making another ruling).
When I use the term 'hack' it usually refers to a solution to a problem that was done usually in response to a pressing issue, and so not a lot of thought went into it in regards to the overall design of the application. Sometimes it works out, sometimes not so much, and sometimes it turns out to be a work of genius. But mainly, it's an admitted temporary solution that (hopefully) gets refactored and refined when possible.
Here's a great sentence I saw about the difference between hacking and scamming and it says, "Hacking attacks are successful when the criminal knows how a particular computer system works. Scams are successful when the perpetrator knows how the human brain works.", which brings the idea out that to hack into something, you need to have a deep understanding of how it works.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 13 years ago.
Often, I am told that Security functions are not available at a level of abstraction that a developer with little security knowledge can use them. What changes will the developers want in their developement environment say for Java that will make securing their software much easier than today.
I am looking at new ways like providing configurability at the level where the programmer just has to declare the security function he desires and the level he wants and only really power programmers will need to go and do something really extra.
So 2 part question - what services will you want as a developer and how would you like it to be integrated into your IDE (your development environment) so that you can easily use it.
where the programmer just has to declare the security function he desires
That's like asking "What type of scalpel can I buy so I don't have to learn doctorin'?"
You can't.
The issue of "security" covers a very broad range of concerns. You don't just "turn on security" and it's done. Security issues involve guarding your software from an ever-growing number of malicious behaviors.
At the root of it, computers have to let people do things. To give users that freedom, people will always find ways of getting into things they are not supposed to get into. The people who write operating systems, frameworks, and development environments can patch holes and abstract away some of today's security concerns but new ones will always be developed. Daily. It's a moving target.
Security is complicated because you have to know what types of vulnerabilities your application can be subject to. The only way to learn that is through vigilant study and experience.
You can't just flip a switch.
The more I think about it, the more I realize that what you want actually exists. Programmers tell the computer what they want it to do in a very specific manner, using well defined languages. The computer is expected to do exactly what the programmer dictates, within the definition of the language. If the programmer wants security, s/he can already tell the computer to act in a secure manner - such as using String classes in C++ to avoid buffer overruns with char arrays.
Of course, this isn't enough. Programmers still get things wrong, so language designers try to help with things like Java. In Java, buffer overruns are much harder to exploit beyond a simple application crash (char[]c = new char[1]; System.out.println(c[10]);).
But that's not really enough - the compiler can have bugs that will insert overruns, or the virtual machine may have such bugs. And other vulnerabilities will exist - like bad permissions on files, or exploitable race conditions (aka TOCTOU).
As we find vulnerability types, we can take steps to prevent them (developer training, new language features, new compiler features, and new OS features), and we can take steps to identify them (dynamic analysis, source code analysis, binary analysis), but we can't eliminate all bugs. This is especially true as new technologies come into play (once XSS and SQL injection were understood, developers started introducing LDAP injection).
OWASP is trying to do this with it's ESAPI project.
The best way for security to work is to have it built into the API, with very context-aware, context-specific programming methods. This is what SqlParameters do, in .NET, and similar things in other languages (they grab as much context as possible; types of variables, and so on, and perform validation).
If you want to get involved, you can probably get in on the OWASP action, as long as you are motivated.
The best way to do security is to let someone else do it, and follow the API and instructions to the letter. But also, you need to have significant trust in the people doing the underlying work, and you need to stay up to date with what is happening with the libraries you use.
On that last point, you also need to stay flexible. If it so happens that a vulnerability is discovered in your underlying system X, then you may need to update or remove it completely (but most likely update). You need to have the facility to do this ASAP. I.e. to swap out hashing functions, or to change encryption routines.
Obviously, this area is complicated and interesting. I suggest to you that OWASP is a good place to get started.
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
I've come across an article that discusses the issue of "code admiration". Basically, the author talks about how developers should be more skeptic about code they write. How we may "admire" our code too much, attach our-self to it, making us more vulnerable to bugs and other mishaps that may be lying in front of us.
How do you feel about this issue? And do you have more tips on how to avoid/be more aware of this issue?
Some years ago, I was working with another on a small "hobby" project, and I realised that we had to re-assess things. We had written lots of code but it wasn't all good code.
We didn't really want to "throw away" all the work we had put in. But I realised something: what mattered most was the amount of work we would need to put in from now on.
We couldn't change the fact that we had already put so much work into the project, so the only way to minimise the total amount of work the project would need, would be to minimise the amount of work we hadn't done yet.
Since that day, I have stopped being attached to my code. If I'm confident that throwing it away and starting from scratch means less work than keeping it and adapting it to my needs, then I'll throw it away.
My high school art teacher used to encourage us to take what we considered to be our best drawings and tear them up; he called this "cleansing the soul". His reasoning was that, as artists, we were driven to create works of art, and any time we produced something that we liked and that gave us satisfaction, our motivation to continue creating would be lessened.
So I followed his advice and tore up my best stuff, and it worked. Instead of spending my time admiring my old work, I created new stuff and continually got better. I've tried to follow the same principle with my code, but it doesn't really work: my computer has a tough plastic shell that is nearly impossible to tear through.
I post a fragment from Jeff Atwood's blog, Sucking Less Every Year, and I agree 100%.
I've often thought that sucking less
every year is how humble programmers
improve. You should be unhappy with
code you wrote a year ago. If you
aren't, that means either A) you
haven't learned anything in a year, B)
your code can't be improved, or C) you
never revisit old code. All of these
are the kiss of death for software
developers.
We sure like to admire our nice code, but it's not always easy to know what to admire. Complicated and elaborate code is sometimes mistaken for admirable code, while elegance and simplicity should rather be what to strive for.
Two quotes come to mind:
"Debugging is twice as hard as writing
the code in the first place.
Therefore, if you write the code as
cleverly as possible, you are, by
definition, not smart enough to debug
it.”
-- Brian Kernighan
and
"Make everything as simple as
possible, but not simpler."
-- Albert Einstein
Jonathan Edwards wrote an impressively beautiful essay on this subject, prompted by the work on the O'Reilly book Beautiful Code. Here's the final paragraph, but the rest of the essay is also worth reading.
Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude. Love is blind, but computers aren’t. A long term relationship – maintaining a system for years – teaches one to appreciate more domestic virtues, such as straightforwardness and conventionality. Beauty is an idealistic fantasy: what really matters is the quality of the never ending conversation between programmer and code, as each learns from and adapts to the other. Beauty is not a sufficient basis for a happy marriage.
Other versions of this same wisdom exist in other fields. Samuel Johnson, about writing:
Read over your compositions, and wherever you meet with a passage which you think is particularly fine, strike it out.
William Faulkner's version of this was much more succinct: “Kill your darlings.”
My father-in-law works as a film editor, and he studiously avoids the set where the film is being shot. When he does have to visit, he shields his eyes as much as he can. This is because when he decides whether or not to include a scene in the final film, he doesn't want to be influenced by how much effort it took to shoot the scene. What matters is how well the scene works in the final film.
My essay, "My evolution as a programmer" (which I would link to if I weren't a new user), is largely about learning skepticism about the code I'd written: whether it works, whether it's useful, whether it's comprehensible (pair programming was a real wake-up call here). It's hard!
I never admire my code. I admire other peoples code that i "borrow" and try and emulate them or better them and i find that the more i know, especially about coding the more i find i don't to know. The only thing of value wold be for peer programmers to admire my code and borrow it.
I think he has a good point. It's frustrating to work with people that have too much of this, as it really hinders teamwork and getting to the best solution to the problem.
As I can be a bit delusional, I try to put practices in place that will keep me grounded in reality. For code,
unit tests: These keep me more focused on what the code is supposed to do, as opposed to any abstract "beauty".
shared code ownership: There are two camps here: give people more ownership of their code and hope pride takes over, or give them less and let peer pressure come into play. I believe that giving people more ownership can lead to this code admiration. We practice shared code ownership, so I am constantly forced to see someone rewrite my perfect code to make it better (in their mind). I quickly realized admiring it too much was a waste of time and emotionally difficult.
pair programming: working side-by-side with someone will keep you realistic.
other feedback: These are all feedback loops, but there are others. There's no better way to see if something works than by watching someone (try to) use it. Put your work in front of as many people as possible. Have code reviews. Read other people's code. Run static code analysis tools.
I'm with PurplePilot - I don't admire my own code, and as such I'm constantly searching for new, more efficient (hell, easier) ways of doing the same thing. I like the Effective c# book, picked up lots of useful code from there that I admire.
I would have no hesitation about throwing code away and starting again, but not necessarily from scratch, i.e. by writing some code for a specific scenario and then throwing it away, you'll probably have a better grasp of the scenario. In other words, it's a "wicked problem", or you've found another way that doesn't work a la Edison.
It begs a wider question: if code isn't thrown away, or at least revisited, is developing on libraries that are becoming stagnant a good thing?
There is nothing wrong with admiring your code ... this is part of the positive reinforcement process that will motivate you to write more and better code in the future.
However, misplaced or misused admiration can be a problem. If the code is really not good, or has bugs that haven't been exposed by unit or other testing, or needs refactoring/redesign/replacement then this misplaced admiratoin is a problem. And using admiration as an excuse to skip part of the process - such as code reviews, or not having a skeptical attitude towards code - is misuse of admiration.
Like anything else that is good, admiration of code can be misplaced or misused - it doesn't mean that it in itself is bad. That would be like saying "religion is a bad thing, because it causes conflicts and wars between people".
Two words: code review.
Gather two or more fellow developers and invite them to review/criticize/comment on your code. 'twill shed some (admittedly harsh) light on your code.
It's perhaps better to have a healthier perspective - we aren't rocket scientists, and we aren't curing cancer - it's just work.
(Yes, it's reasonable to be proud of an entire building you helped build if you're an architect, but do they really have a lot of their self-esteem wrapped up in an individual blueprint, or a closet on floor 3 they designed by themselves?).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Are there any statistics for this? I realize it must vary from person to person, but it seems like there should be a general average.
The reason I ask is that the company I contract for has multiple software products, totaling ~75,000 lines of code - and they seemed disappointed and shocked when they ask me a question about a specific portion that I don't immediately know the answer to (I am the only programmer they have, and did not author the majority of the systems) They think I should just know it all from memory. So I wanted something like a statistic to show them that an average programmer couldn't possibly have all that in his head at one time. Or should I?
You should remember where to find the needed stuff not remember it itself.
You should also be familiar with code structure and architecture enough to make an educated guess where a problem might originate and where you could possibly find the stuff you know exist but not sure where exactly.
You brain works like cache. The stuff you used recently is kept there, more older entries are erased. But there will never be enough memory to remember the code all at once. Because then you will want to remember all API functions, then all specs, then something else. This all is not feasible.
And being surprised with you that you don't remember all the code is probably one more instance of those perversed notions of how programmers do things. Ignore them.
It depends not only on your memorization skills, but also a lot on the code. Obviously, clean, idiomatic code is much easier to memorize than a badly written inconsistent mess.
Probably because clean code can be broken down into much larger "abstract tokens".
Indeed interesting question but I am in doubt if there is adequate answer at all. Here are only obvious factors I see right from the start:
Overall design quality. Even if you are new in well designed code you can very quickly identify where you should look to get answers.
Project documentation quality. For poor documented projects even developers that are in project from the start can't say anything about some parts.
Implementation quality. OK. You have good general architecture, good documentation for interfaces but even one really bad programmer could break all of this. This is because many companies are very strict about code reviews and I think it is the only one technique to prevent such situation.
Programmer experience. As you move ahead you see number of 'already known' code "bricks" in software new to you and experience is great help in this so contractors are often very experienced specialists familiar with various approaches and this gives average contractor ability to move much faster then full time programmer which is brilliant but worked 10 years in only 1 project context.
General person smartness. My opinion this is really not so important as most of others factors but it is really important.
... but the common problem is often companies hire contractors for some existing software improvement and they simply think this is only about to hang picture on the wall. You should perform some negotiation to force them to understand part of work is to understand what really should be done to meet their requirements at all. And such "learning" requires resources and is part of work itself. But I think it is slightly off-topic for StackOverflow (despite I voted up ;) ). Is it more for Startups discussion?
Even if you have written all that code you might forget portions of it. But you'll be able to recall it once you review it.
I think its natural for a programmer to forget some portions of his/her code after a long time.
Ask them how they want you to spend your time: surveying vast amounts of code you didn't write and perhaps writing up internal documentation, or whatever currently keeps you occupied It's not a facetious question. If they want quicker response to new issues, they need to invest in research.
I don't think there's a meaningful answer to this measured in LOC. As a manager, what I want to know is that someone in your situation can answer a question in a reasonable amount of time -- and unless I know you're in the middle of something, I wouldn't expect that 'reasonable amount of time' to be 'instantaneously'.
You should be able to understand all the components within the system and how they interact so that when there is a problem you can isolate one or two likely components and drill down.
I find it helpful to draw a few diagrams and keep them handy so I can use them to communicate with my boss\customer as well as jog my memory.