Home/ Questions/Q 393535
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T16:16:02+00:00

Quickie pseudo-aesthetics question: For field declarations, the following is allowed: int i, j, k;

  • 0

Quickie pseudo-aesthetics question:

For field declarations, the following is allowed:

int i, j, k;

providing three variables for integers. Does anything similar exist for method declarations, ala:

public int getI() {/* ... */},
getJ() {/* ... */},
getK() {/* ... */};

so that the method accessibility, return type, etc don’t have to be redundantly specified? I can imagine some cases where this sort of syntax would seem really beneficial (e.g., methods with an assortment of argument sets allowed), so I’m hoping it’s in there somewhere. I’ve tried the above, and it doesn’t seem to work.

EDIT: relative to KLE’s question about needs, there isn’t a requirement, it’s more about wants. The most annoying thing I’m facing is that I have a class of a bunch algorithms that are static (and should be static, as they don’t depend on anything but their arguments) but take a generic argument with some restrictions. The restrictions are the same for every method, and it really uglies up the code to have to repeat them for every method, but putting them in the class definition (i.e., public class Foo<U extends Bar>) seems to preclude making the methods static.

ALSO: Can someone elaborate on why using sharing the fields declaration is considered bad practice? I think I can appreciate that perspective in the commercial application realm, but it seems a little strange in the scientific application realm – sharing types fields seems an obvious and simple means of indicating when things should be the same kind of thing.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is considered bad form for fields, especially once generics are involved. Consider this (real world case) of pre generic code:

    private Map a = new HashMap(), b = new HashMap();

    Now a and b had different contents (their generic types would be different). This was java 1.3/1.4 code, so it didn’t matter. But now, when I have to add generics, that has to be split apart, and it becomes a more involved change. The declaration of int i, j; would probably not exist if not for the fact that C/C++ has them.

    So for your method declarations, sure it saves some boilerplate, but at the sacrifice of readability and maintainability. Readability in the sense that the declaration could be tens or hundreds of lines away from the rest of the method. Maintainability in terms of what if one of those methods in the middle of that chain had to change their generic type? Now you have a whole bunch of code that has to be moved around, and you have to get those commas right.

    Now this isn’t the biggest deal, especially with a modern IDE, but the bottom line is really is that Java is just not terse language, and it values expressiveness and clarity over concise expression.

    In some cases, that hurts DRY, but in this case the fact that these methods have the same return type is simply coincidental and it isn’t a true repetition to re-declare them.

    Anyway, a macro expansion, if anything, would be a more appropriate way to solve this problem (not that Java is getting that any time soon).

    • 0