-2
$\begingroup$

I was having a heated debate with a friend of mine (who considers me an idiot, mind you) and we were arguing about whether a compiler has an index, or coefficient, that judges how poorly code is written. Things such as useless for loops, declared variables that aren't used, excessively verbose parameter names, and the likes. He told me that there is no such "stupid" thing. I got mad and told him that the index exists and that smart people writing compilers wanted to make the compiler have "feelings" where it would analyze the code, generate the coefficient using an algorithm, and change how well it compiles the code based of how poorly the person wrote the code.

I guess, to alleviate any confusion, what I'm asking is, do compilers have feelings? Err, well not literally, figuratively, by using an algorithm and code quality coefficient.

All answers are greatly appreciated! Thank you!

|cite|improve this question
$\endgroup$
  • 2
    $\begingroup$ I'm wondering what assured you in your position. Did you have any evidence that a compiler produces different results if, for example, the developer uses excessively verbose parameter names? What observations lead you to the conclusion of the existence of such index? $\endgroup$ – Mike B. Jul 13 '15 at 11:29
  • 4
    $\begingroup$ I'm voting to close this question as off-topic because buhhhhhhhhh? $\endgroup$ – David Richerby Jul 13 '15 at 13:28
  • $\begingroup$ The question is quite silly when it gives feelings to programs. Someday, maybe. But there are quite a few good questions lurking behind. The answers are not bad. BTW, I have know some compilers who had feelings: these were people translating by hand a source code into assembly language. $\endgroup$ – babou Jul 14 '15 at 21:52
  • 1
    $\begingroup$ AI for the sake of...? $\endgroup$ – Juho Jul 20 '15 at 5:45
  • 1
    $\begingroup$ for the sake of...being a worse compiler than it could be, according to the question. The friend in the story got it spot on: It would be a stupid thing. I'm still wondering what assured the author that such index would exist. $\endgroup$ – Mike B. Jul 23 '15 at 10:35
7
$\begingroup$

So, something similar to what you're describing exists, but not the way exactly.

A compiler can't generally identify "bad" code. In particular, it cannot usually fix incorrect code. If you make a mistake, not only is it undecidable for the compiler to tell if you made a mistake, but there's no specification of your program for the compiler to compare to, determining if it is a mistake.

There are some general exceptions to this, the most notable one being typechecking. But there, the compiler isn't keeping any sort of coefficient, it just rejects poorly-typed code, or emits a warning.

For improve code, there is a part of the compiler called an optimizer. It will look for easy tricks that will speed up your code. Some of its tools include:

  • Reordering instructions to improve speed
  • Replacing a function with its definition, to reduce the overhead of calling a function (inlining)
  • Evaluating expressions only involving constants
  • Removing run-time safety checks when it knows they're not needed
  • Storing sub-expressions that are used more than once

However, this is not at all focused on "bad" code. It is more focused on finding ways to generate fast machine code in a way that is simply not practical to do by hand. Writing code using functions is certainly not bad, but the compiler is able to make it faster in a way that a good programmer would never write.

The compiler can't do magic. If you use a slow algorithm, like BubbleSort instead of QuickSort, the compiler can't fix that for you.

There are some measures of code quality, but these are generally not included in a compiler. Rather, they are part of separate code-auditing tools.

|cite|improve this answer
$\endgroup$
  • $\begingroup$ Thank you very much for the amazing and detailed answer! That answers everything I was trying to ask (in my poorly written question). :) $\endgroup$ – Rogue Shakuras Jul 13 '15 at 5:13
  • $\begingroup$ "it will never correct incorrect code" -- This absolute statement is wrong. There are compilers that can prove (in)correctness of some programs (of course not all). Also, what are all these warnings about that javac throws at me? $\endgroup$ – Raphael♦ Jul 13 '15 at 11:06
  • $\begingroup$ It might warn you about bad code, but it won't silently correct it for you. I've updated the answer to hopefully be clearer. $\endgroup$ – jmite Jul 13 '15 at 18:23
  • $\begingroup$ Indeed, there can be a case where the compiler actually fixes your code for you, accidentally. For instance, your code might rely on undefined behaviour, and it just so happens the compiler does something nice for it. Compiled with another compiler, the program could crash at the same point. But anyway, I think your update was OK. $\endgroup$ – Juho Jul 15 '15 at 10:01
1
$\begingroup$

It's generally true that compilers are designed with reasonably-written code in mind. Automatically generated code (to pick one example) often triggers pathological behaviour in immature compilers. That sort of thing makes for a great test case.

jmite is correct that compilers don't really have a notion of "bad code". A compiler is not allowed to turn legal input into incorrect output.

Apart from compiler-detectable errors (e.g. type errors), in some languages (most notably C) there is a notion of "undefined behaviour". If you write code which exhibits undefined behaviour, the compiler may be allowed to do whatever it likes, including nasal demons.

Having said that, that some code, while correct, is so "bad" that it is not worth a compiler writer's time to try to do anything useful with it. If we ignore floating point roundoff for a moment, a compiler could optimise this:

x = sin(theta)*sin(theta) + cos(theta)*cos(theta);

into this:

x = 1.0;

It would save a lot of time, too; transcendental functions are quite expensive as these things go. In that sense, it looks like a great optimisation.

But is it actually worth the compiler's time to look for this sort of thing? The attitude among compiler writers is that if you write this, you deserve the generated code that you get. There are far more important things that the compiler should spend its time optimising.

So badly-written source code may result in inefficient target code.

|cite|improve this answer
$\endgroup$
  • $\begingroup$ So what are all these warnings about that javac throws at me? $\endgroup$ – Raphael♦ Jul 13 '15 at 15:09
1
$\begingroup$

A compiler is first and foremost a translator. Therefore, if you feed bad code to a compiler, it will probably output bad code.

But a compiler does not have any form of code quality index that controls compilation quality. It may produce a warning that a variable is unused (helps detect bugs), and it might optimize useless loops (makes code faster), but it won't care how one names variables: A compiler is a tool, designed to help the developer, not hinder their work. With that in mind, deliberately worsen a compiler's quality seems indeed like a stupid thing to do.

|cite|improve this answer
$\endgroup$
  • $\begingroup$ So what are all these warnings about that javac throws at me? $\endgroup$ – Raphael♦ Jul 13 '15 at 15:09
  • $\begingroup$ That depends on the warning, but I don't think warnings satisfy the condition in the question, where the compiler would "analyze the code, generate the coefficient using an algorithm, and change how well it compiles the code based of how poorly the person wrote the code". I wrote some really bad java in my days, but (unfortunately) I never got a warning that my code is crap. $\endgroup$ – Mike B. Jul 13 '15 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.