2

Many IDEs have the ability to spit out automatically written pieces of code. For example, it might generate a getter/setter pair for you. I wonder whether it isn't an attempt to work around some flaws in the language. If your IDE can figure out what the code should be without your help, why can't the compiler?

Are there cases where this is a really good idea? What kind of code generation does your IDE provide? Would the same thing be better provided as a feature of the language?

Improve this question
  • The IDE can, but you still have to tell it you want it. – user1249 Nov 19 '10 at 4:57
  • and what prevents your language from adding it when you request it as well? – Winston Ewert Nov 19 '10 at 5:22
  • Most of the time it helps you in rapid development. You can tinker code the way you want later. – PradeepGB Nov 19 '10 at 7:18
  • 1
    Whatever it is, the language does add it when you request it - that's what programming is. – Paul Butcher Nov 19 '10 at 9:28
  • @Winston Ewert: This would tie the language to specific technologies, which probably isn't what you want. E.g., having C++ spit out .NET assembly directives makes it less attractive to people doing Android development. – TMN Nov 19 '10 at 14:25

11 Answers 11

Active Oldest Votes
8

The difference between the IDE auto-generating some code and building that directly into the language is very simple: I can edit the code after the IDE generates it.

The IDE can generate some code template for a getter/setter, and then I am free to add additional functionality to that getter/setter as my requirements dictate. If the getter/setter was an integrated part of the language, then if I ever wanted to customize the behaviour, I'd have to write the getter/setter myself anyway...

Improve this answer
  • The ability to modify the code is a good point. – Winston Ewert Nov 19 '10 at 13:52
  • 3
    You've never used Lisp, I take it. It's perfectly possible to edit Lisp macros after writing them, and abstracting this at the language level rather than the IDE level reduces boilerplate (which makes it easier to change later, not more difficult). – Inaimathi Nov 19 '10 at 15:03
5

When I code in Ruby, I use vim, and I feel good. I mean, I don't want or need any kind of autocompletion / code generation.

On the other side, when, I code in Java, I use Eclipse (or Netbeans) and I could not work without it. I need to easily generate the getters/setters, the big try/catch block, I'm happy if the IDE can help me with the for each loop.

I wonder whether it isn't an attempt to work around some flaws in the language

Ruby getter + setter + variable for my_var:

attr_accessor :my_var

Java getter + setter + variable for myVar:

private String myVar;
public String getMyVar() {
  return myVar;
}
public void setMyVar(String value) {
  myVar = value;
}

Yes, in Java, I need to generate that code...

So... Is it an attempt to work around some flaws in the language ? I'm tempted to answer YES, but I might be too much biased...

Improve this answer
  • Its not a flaw its a tradeoff - one of the key points in Ruby and more so in Ruby on Rails is that its opinionated, do things this way. So you give up flexibility to gain simplicity which may have a cost at some point if what you need to do doesn't fit in the box. – Murph Nov 19 '10 at 8:54
  • 1
    By the way, Ruby is the kind of language where you can do things in many different ways (don't talk about Rails, it is only a framework, though it forces you to things in the rails way yes). I don't see how you give up flexibility when you use Ruby as a language. – David Nov 19 '10 at 9:09
  • 1
    Java and Ruby are just examples - there's a whole argument about strongly typed vs weakly typed. About compiled vs interpreted vs something in betweeen. Almost any language is a compromise that promotes some features and capabilities at the expense of others. Where you write less code you tend to have a language that makes more assumptions about how things should be done (or use more symbols c.f. APL and write only code) – Murph Nov 19 '10 at 10:04
  • 1
    @David - yes, absolutely and mine is that there ain't no such thing as a free lunch so what you gain by having the support you may lose elsewhere by the constraints you have to work within. This is not an absolute - languages evolve and improve building upon what has gone before. – Murph Nov 19 '10 at 13:22
  • 2
    If your language forces you to use getters and setters as a matter of course, why don't you go out and find a real object-oriented language, or even something closer like C++? – David Thornley Nov 19 '10 at 15:26
4

Think of the ambiguity you would introduce into pretty much any language if you let the compiler/interpreter try to guess what meant.

Improve this answer
  • 2
    Then go program in PL/1 for a while to experience it. – Tim Williscroft Nov 19 '10 at 5:15
3

With getters and setters, you don't always want both, but how is the compiler/interpreter to know that?

Also, when using the class, you'd have to remember on your own that a certain property is read-only, instead of having it clearly in the code that you can't use a setter because it doesn't exist.

Improve this answer
3

The Groovy language does exactly this, getters and setters are generated on the fly. But I must admit that too much magic always makes me wonder what the program really does, since there are too many things to keep in mind that happen behind the curtain. Explicit getters and setters, as generated by the IDE, make it a bit easier to follow the flow of the program.

Improve this answer
2

Code generation from a Domain-Specific Language, to let you focus on writing what matters, is good.

Code generation from an IDE, to create boiler-plate code, is a sign the language sucks.


Your specific example - generating getters and setters* certainly shows a language problem.
You should only be writing a getter/setter if it does something - but if it's generic that doesn't mean you let the IDE generate it, it means you don't need it in the code at all. (Don't waste developer brain power figuring out if a function is generic or if it has a subtle difference - just leave the 'empty' functions out.)


Oh, and whilst technically IDE-based code generation, snippets/templates, - i.e. typing fpubstr and getting public string function( ) or equivalent - is also a form of immediate DSL-based generation, and thus a good thing (an actual language which had commands like fpubstr/fpubint/fprvint would be horrible to read).


* Ignoring temporarily that getters and setters are more than likely a sign of bad OO design.

Improve this answer
  • +1 for your footnote. I'm glad somebody else realizes that. – David Thornley Nov 19 '10 at 15:31
2

I can't improve on Charles Petzold's excellent "Does Visual Studio Rot The Mind?" (http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html). I think that the IDE and code generation in general has its place but if you as a developer do not already know why it is doing what it's doing (in the case of code generation having written the templates yourself, preferably) then you are flying blind. Being able to build something from scratch in a text editor is a good indication that you understand what's going on. That said it would be foolish to insist on only ever writing every last line from scratch by yourself every time you have to get something done.

Improve this answer
1

To me, I would like to think that IDEs should help the users generate codes to

  • increase your coding speed e.g. generation of mundane (subjective) codes
  • give (to a certain extent) an idea of how certain 'requirements' can be coded e.g. template for a specific class types

The codes by no means should be taken for granted to fit exactly what you want.

However, codes generated from visual editors/wizards (e.g. WinForm designer generating the designer.cs files) should not be meddled with unless you have deep understanding of what you are doing and prepared to get screwed if it affects the visual editor's ability to render the design-time view.

Improve this answer
1

This feature can be taken away from the compiler proper and be given a name of its own. This need not be a language feature. There can be generic template generators or skeleton code generators.

They could sit somewhere in between compiled languages and interpreted languages. By taking them away from the compiler proper, you do not unnecessarily fatten it up. Not everyone will be using every template.

If it need not be provided by the compiler, the language need not provide it as a feature.

Improve this answer
  • Good point that we can avoid adding this stuff to the compiler. I wonder if a macro facility might be a possible way to accomplish the same goal? – Winston Ewert Nov 19 '10 at 13:53
  • Traditional macro facilities have always been limiting, but perhaps a language that supported "extension points" of some sort. Interpreted languages (LISP, Smalltalk, FORTH) have supported this, I don't think I've ever seen a compiler that could handle it, though. – TMN Nov 19 '10 at 14:56
1

For getters/setters, that is true for Java (which I guess is what you are talking about) since that language lacks properties as a language construct. The IDE can help you compensate for that somewhat.

Improve this answer
  • Why is there this intense desire to break encapsulation and extend the class public interface into the internals? – David Thornley Nov 19 '10 at 15:20
  • @David: What are you trying to say? – Martin Wickman Nov 19 '10 at 15:23
  • 1
    @Martin: Getters and setters are only one step in the right direction from making all the data members public. They expose class implementation, and allow other code to meddle with internals. If you have getters and setters as a matter of course, you can kiss the idea of class invariants goodbye. In short, getters and setters, when used more or less automatically, are ways to disguise the fact that you aren't really using OOP. – David Thornley Nov 19 '10 at 15:30
  • @David: Yes, I know that. It's OO 101. I never said one should break encapsulation or misuse properties, so whats with the lecturing? – Martin Wickman Nov 19 '10 at 15:45
  • @Martin: Why do so many people in this question seem to think that getters and setters, or for that matter properties, are good enough things that making them easier to do is valuable? I'd rather make it harder to do them, in the hope of discouraging bad OO. – David Thornley Nov 19 '10 at 16:02
0

IDE code generation is indispensable for generating things like method stubs for SOAP endpoints or serialization classes from an XML schema. These are things that are outside the scope of a language but are certainly within the purview of a "development environment".

I do think Java's accessors are clumsy, though. I always thought they should be more "virtual": that is, obj.field = value implicitly calls obj.setField(value). If the class declares a setField(), then that is used, otherwise the run-time just conses one up. ISTR Ruby does something like this. The JSTL EL does this, but it just generates a call to a setter, and if that doesn't exist the call fails.

Improve this answer
  • I think the reason they chose not to do this was because they wanted people to be explicit about which one they were calling. While I understand their concern, I think properties have a lot more to offer than getters/setters. – jsternberg Nov 19 '10 at 17:24

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.