Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #36162 > unrolled thread

can someone chk is this code ok and if i can make it better please state how

Started bySuperGiirl <kainattshafiq90@gmail.com>
First post2017-01-06 12:38 -0800
Last post2017-01-07 11:39 -0800
Articles 9 — 6 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  can someone chk is this code ok and if i can make it better please state how SuperGiirl <kainattshafiq90@gmail.com> - 2017-01-06 12:38 -0800
    Re: can someone chk is this code ok and if i can make it better please state how SuperGiirl <kainattshafiq90@gmail.com> - 2017-01-06 12:52 -0800
      Re: can someone chk is this code ok and if i can make it better please state how Andreas Leitgeb <avl@logic.at> - 2017-01-06 21:11 +0000
        Re: can someone chk is this code ok and if i can make it better please state how SuperGiirl <kainattshafiq90@gmail.com> - 2017-01-06 14:02 -0800
    Re: can someone chk is this code ok and if i can make it better please state how Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-01-06 16:15 -0500
      Re: can someone chk is this code ok and if i can make it better please state how Robert Klemme <shortcutter@googlemail.com> - 2017-01-07 14:16 +0100
    Re: can someone chk is this code ok and if i can make it better please state how lewbloch@gmail.com - 2017-01-06 17:23 -0800
    Re: can someone chk is this code ok and if i can make it better please state how Robert Klemme <shortcutter@googlemail.com> - 2017-01-07 14:23 +0100
    Re: can someone chk is this code ok and if i can make it better please state how galt_57@hotmail.com - 2017-01-07 11:39 -0800

#36162 — can someone chk is this code ok and if i can make it better please state how

FromSuperGiirl <kainattshafiq90@gmail.com>
Date2017-01-06 12:38 -0800
Subjectcan someone chk is this code ok and if i can make it better please state how
Message-ID<e69219b6-6d90-4d99-9e0c-485e867fded4@googlegroups.com>
public class Gadget
{
    private int Weight;
    private double Price;
    private String Model;
    private String Size; 

    
    public Gadget(int theWeight, double thePrice, String theModel, String theSize)
    {
      Weight = theWeight;
      Price = thePrice;
      Model = theModel;
      Size = theSize;
    }

    
    public int getTheWeight()
    {
        
        return Weight;
    }
    public double getThePrice()
    {
        return Price;
    }
    public String getTheModel()
    {
        return Model;
    }
    public String getTheSize()
    {
        return Size;
    }

[toc] | [next] | [standalone]


#36163

FromSuperGiirl <kainattshafiq90@gmail.com>
Date2017-01-06 12:52 -0800
Message-ID<bbd1a3d2-9f01-45b7-891a-1fe4605cc57a@googlegroups.com>
In reply to#36162
On Friday, January 6, 2017 at 8:38:28 PM UTC, SuperGiirl wrote:
> public class Gadget
> {
>     private int Weight;
>     private double Price;
>     private String Model;
>     private String Size; 
> 
>     
>     public Gadget(int theWeight, double thePrice, String theModel, String theSize)
>     {
>       Weight = theWeight;
>       Price = thePrice;
>       Model = theModel;
>       Size = theSize;
>     }
> 
>     
>     public int getTheWeight()
>     {
>         
>         return Weight;
>     }
>     public double getThePrice()
>     {
>         return Price;
>     }
>     public String getTheModel()
>     {
>         return Model;
>     }
>     public String getTheSize()
>     {
>         return Size;
>     }

can someone please explain how to do the mutator method 

[toc] | [prev] | [next] | [standalone]


#36164

FromAndreas Leitgeb <avl@logic.at>
Date2017-01-06 21:11 +0000
Message-ID<slrno7021c.pvm.avl@logic.at>
In reply to#36163
Possible improvements:
 - adding the missing close-brace for the class at the end.
 - There exist styling conventions for casing (upper/lower) of
     identifiers. Most of the identifiers are ok, except those
     for the fields. MixedCase with an initial capital should
     be used only for class-names.
 - Unless "the" is part of the field name, it shouldn't be
     included into accessor methods' names.

As for mutator methods: here's an example (assuming that the
fields have been renamed to lowercase initial):

...
     private int weight;
...
     public void setWeight(int weight)
     {
         this.weight = weight;
     }
...
     public int getWeight()
     {
         return weight;
     }
...
ditto for the other fields.


SuperGiirl <kainattshafiq90@gmail.com> wrote:
> On Friday, January 6, 2017 at 8:38:28 PM UTC, SuperGiirl wrote:
>> public class Gadget
>> {
>>     private int Weight;
>>     private double Price;
>>     private String Model;
>>     private String Size; 
>> 
>>     
>>     public Gadget(int theWeight, double thePrice, String theModel, String theSize)
>>     {
>>       Weight = theWeight;
>>       Price = thePrice;
>>       Model = theModel;
>>       Size = theSize;
>>     }
>> 
>>     
>>     public int getTheWeight()
>>     {
>>         
>>         return Weight;
>>     }
>>     public double getThePrice()
>>     {
>>         return Price;
>>     }
>>     public String getTheModel()
>>     {
>>         return Model;
>>     }
>>     public String getTheSize()
>>     {
>>         return Size;
>>     }
>
> can someone please explain how to do the mutator method 

[toc] | [prev] | [next] | [standalone]


#36167

FromSuperGiirl <kainattshafiq90@gmail.com>
Date2017-01-06 14:02 -0800
Message-ID<91f4ffb3-1d1b-4287-a55a-305b730302cd@googlegroups.com>
In reply to#36164

thank youu 

[toc] | [prev] | [next] | [standalone]


#36165

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2017-01-06 16:15 -0500
Message-ID<o4p1ae$4bv$1@dont-email.me>
In reply to#36162
On 1/6/2017 3:38 PM, SuperGiirl wrote:

     For future reference: It's best not to rely on the "Subject" line
to convey your question.  Rather, use "Subject" simply as a title and
ask your question in the body of the message.

     That said, the code is "OK" but there are opportunities to improve
it in small ways.  I'll point out a few ...

> public class Gadget
> {
>     private int Weight;
>     private double Price;
>     private String Model;
>     private String Size;

     It is customary ("conventional") to use Initial Capital Letters for
the names of classes and interfaces, but to use initial lowercase for
variables and methods.  The code is "OK" in the sense that it compiles
and executes without trouble, but would be more readable if you used the
naming conventions readers are familiar with.  ifyoudontthinkclarityis
atleastinpartamatterofconventionthinkagain  For more information, see

http://www.oracle.com/technetwork/java/codeconventions-135099.html

     Also, if the values are never intended to change after being set in
the constructor (and you show no code that might change them), it would
be a good idea to declare them as `final' variables.

>     public Gadget(int theWeight, double thePrice, String theModel, String theSize)
>     {
>       Weight = theWeight;
>       Price = thePrice;
>       Model = theModel;
>       Size = theSize;

     This would be a good place to perform sanity checks on the values:
A negative weight is probably nonsensical, as is an infinite price or
a null or absent model name and size.  The code would be more "robust"
if the constructor checked such things and objected to craziness by
throwing an exception:

	if (theWeight <= 0)
	    throw new IllegalArgumentException(
	        "bad weight: " + theWeight);
	if (thePrice <= 0.0 || !Double.isFinite(thePrice))
	    throw new IllegalArgumentException(
	        "bad price: " + thePrice);

... and so on.  The principle is that the sooner a mistake is found,
the easier it will be to fix.  If a crazy price puts up a red flag as
soon as it appears, it'll be easier to figure out where it's coming
from than if it slips quietly into the mix along with thousands of
other Gadgets and your only clue is an absurd cash-flow total at the
end of the quarterly inventory reconciliation report.

>     }
>
>     public int getTheWeight()
>     {
>
>         return Weight;
>     }
>     public double getThePrice()
>     {
>         return Price;
>     }
>     public String getTheModel()
>     {
>         return Model;
>     }
>     public String getTheSize()
>     {
>         return Size;
>     }

     The "The" parts of these method names don't communicate much, and
seem to be little more than clutter.  (Why not "getThatWeight" or
"getAPrice"?)  It would be more usual to use names like "getModel"
and "getSize" instead.

     Summary: OK, but improvable.

-- 
esosman@comcast-dot-net.invalid
"Nobody ever went broke underestimating the intelligence of the
American public." -- HLM (paraphrased)

[toc] | [prev] | [next] | [standalone]


#36169

FromRobert Klemme <shortcutter@googlemail.com>
Date2017-01-07 14:16 +0100
Message-ID<edc810FmmbfU1@mid.individual.net>
In reply to#36165
On 06.01.2017 22:15, Eric Sosman wrote:

>     The "The" parts of these method names don't communicate much, and
> seem to be little more than clutter.  (Why not "getThatWeight" or
> "getAPrice"?)  It would be more usual to use names like "getModel"
> and "getSize" instead.

Another remark about naming of methods and fields: the current state of 
affairs does not adhere to the Java Beans spec and usual convention for 
getters and setters.  So it would be

private String model;

public String getModel() {
   return model;
}

Kind regards

	robert
-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]


#36168

Fromlewbloch@gmail.com
Date2017-01-06 17:23 -0800
Message-ID<e7506c40-ea1f-4008-93e8-e8ca807b5cdc@googlegroups.com>
In reply to#36162
On Friday, January 6, 2017 SuperGiirl wrote:
> public class Gadget
> {
>     private int Weight;
>     private double Price;
>     private String Model;
>     private String Size; 
> 
>     
>     public Gadget(int theWeight, double thePrice, String theModel, String theSize)
>     {
>       Weight = theWeight;
>       Price = thePrice;
>       Model = theModel;
>       Size = theSize;
>     }
> 
>     
>     public int getTheWeight()
>     {
>         
>         return Weight;
>     }
>     public double getThePrice()
>     {
>         return Price;
>     }
>     public String getTheModel()
>     {
>         return Model;
>     }
>     public String getTheSize()
>     {
>         return Size;
>     }

In addition to the excellent advice others have offered, look into providing Javadoc comments, the ones that begin with `/**` (slash-star-star) and precede public and protected declarations such as your method declarations. You can find out all about Javadoc comments and the documentation they generate using `javadoc` in the Oracle Java documentation.

-- 
Lew

[toc] | [prev] | [next] | [standalone]


#36170

FromRobert Klemme <shortcutter@googlemail.com>
Date2017-01-07 14:23 +0100
Message-ID<edc8e3Fmrq9U1@mid.individual.net>
In reply to#36162
On 06.01.2017 21:38, SuperGiirl wrote:
> public class Gadget
> {
>     private int Weight;
>     private double Price;
>     private String Model;
>     private String Size;
>
>
>     public Gadget(int theWeight, double thePrice, String theModel, String theSize)
>     {
>       Weight = theWeight;
>       Price = thePrice;
>       Model = theModel;
>       Size = theSize;
>     }
>
>
>     public int getTheWeight()
>     {
>
>         return Weight;
>     }
>     public double getThePrice()
>     {
>         return Price;
>     }
>     public String getTheModel()
>     {
>         return Model;
>     }
>     public String getTheSize()
>     {
>         return Size;
>     }

Yet another addition to the other remarks: some of the types look 
suspicious and might be better changed, depending on the intended usage 
of the class.

int for weight might be OK, but if it is in kilograms and needs to 
express grams (i.e. fractional values) a double might be more 
appropriate.  Definitively state the unit in the JavaDoc.

You can get easily into trouble when representing prices as double. 
Apart from the missing currency (again: state in JavaDoc if it is fixed) 
the impedance mismatch between binary representation of double and 
decimal usage of prices might cause trouble when doing calculations.

Using String for a size seems quite wrong.  Either size is represented 
by some abstraction (e.g. S, M, L, XL, XXL) or by some measurement 
(16cm) so for the former you would use an enum and for the latter a 
numeric type or a type combining a measurement and a unit.

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]


#36171

Fromgalt_57@hotmail.com
Date2017-01-07 11:39 -0800
Message-ID<e71995e3-8f83-43aa-8556-28a1ab7a94fc@googlegroups.com>
In reply to#36162
On Friday, January 6, 2017 at 2:38:28 PM UTC-6, SuperGiirl wrote:
> Can someone chk is this code ok and if i can make it better
> please state how...

As others have mentioned your capitalization and naming are a bit
off from the standard Java conventions. Also it is good practice 
to override the toString method in a class, because this can be 
quite useful (even during debug).

@Override
public String toString(){
  return "Gadget- model:" + this.model +
         " weight:" + this.weight +
         " price:" + this.price
         " size:" + this.size; 
} // end of toString

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web