Imoprtant - naming conventions

  • Thread starter Thread starter Koliber (js)
  • Start date Start date
K

Koliber (js)

sorry for my weak english

I want to put here this tematique:

What do you do to ensure that your names in code are good.

I think that
1) structure - of a code is about half work/invention programmer do
the second is the
2) names

personnaly I was (when I started to code in work) verry terrified
and always in bad mood because of my troubles with names
- it is alwayst very bad - i think i do it bad and this - names -
is very hard

now I am still veru unpleasant of my names
and I do not have worked out good rules I havent worked out
many rules at all,

one rule I try to use always is that the type (SomeClass)
i begin with uppercase letter where an instance (someClass)
with lowercase

also I often (if this is adewuate i would say) try name objects
same as types but with lowercase, like

SomeClass someClass = new SomeClass()
StringBuilder stringBuilder = new StringBuilder()

It seems very very god for me personnaly because
I can then not think (which is for some unknown reason
hard for me what name to chose)

I think I (Here I talk about me only and my troubles) should prefer
such
techniques which let me to forget about name - than try
to be very descriptive - because If I will be try to be good
descriptive I think I will be realy good maybe in it and
it slows down always me a lot and bad thing - I was
always unhappy of result (of tryin to write a good descriptive
names) (especially when i code in work - in home
i was always much more at ease.

It is often a need to have a names that are like that "foo"
or "bar" I heard about but I do not espacially like
- names that shoulb be rather an invisible and
not descriptive - becouse for sure i think many micronames
in code shouldnt be descriptive

The second (after the techniques of creating not important non
descriptive 'invisible' names) thing is - how are the good and easy
rules
of avoid troubles in name-choosing in coding (such that
one I recall in this moment that class and instance names names
should be noun and method names shoul be verb)

The third is how to chose names if you decide write
a code with good descriptive names. It is so hard for me
that I am really almost afraid - it is very hard thing - it all.

:(
K.
 
Koliber (js) said:
sorry for my weak english
Click to expand...

English is not my first language either, but as long as you try your best,
it is ok.
one rule I try to use always is that the type (SomeClass)
Click to expand...

This is called PascalCasing
i begin with uppercase letter where an instance (someClass)
with lowercase
Click to expand...

This is called camelCasing.
SomeClass someClass = new SomeClass()
StringBuilder stringBuilder = new StringBuilder()
Click to expand...

You are doing the right thing.
But I tend to cheat a bit with non-entity classes. Like this:

Customer customer = new Customer(); // using customer as name as it is a
business-object

StringBuilder sb = new StringBuilder(); // using the short sb as it just a
simple stringbuilder
SqlCommand comm = new SqlCommand(); //using the shorter comm, as it is used
in a using-block

I think I (Here I talk about me only and my troubles) should prefer
such
techniques which let me to forget about name - than try
to be very descriptive - because If I will be try to be good
descriptive I think I will be realy good maybe in it and
it slows down always me a lot and bad thing - I was
always unhappy of result (of tryin to write a good descriptive
names) (especially when i code in work - in home
i was always much more at ease.
Click to expand...

Being descriptive is important. Consider this:

List<Customer> list = new List<Customer>(); // bad. we know it is a list,
but a list of what?
List<Customer> customerList = new List<Customer>(); //better. while we now
know it is customers, it is redundant to append list to the name

List<Customer> customers = new List<Customer>(); // best. customers in
pluralis says it all.

It is often a need to have a names that are like that "foo"
or "bar"
Click to expand...

Only in examples. If you code with those name in production-code, you should
be taken out and shot! =)
Also, calling a string 'str' or anything 'temp' should be criminal!
The third is how to chose names if you decide write
a code with good descriptive names. It is so hard for me
that I am really almost afraid - it is very hard thing - it all.
Click to expand...

With VS 2005 and 2007 you get great refactoring support.
Makes it easy and safe to change names, why you don't have to be so
definitive when you name stuff.

:(
K.
Click to expand...
Happy Coding
- Michael S
 
Hi,

Koliber (js) said:
sorry for my weak english

I want to put here this tematique:

What do you do to ensure that your names in code are good.

I think that
1) structure - of a code is about half work/invention programmer do
the second is the
2) names
Click to expand...

You can find a lot of thread about this in the archives, take a look at
them.

Also MS has a recommendation in place (checked when you use FxCop). Do a
search for ".net naming conventions" to find them
 
English is not my first language either, but as long as you try your best,
it is ok.


This is called PascalCasing


This is called camelCasing.


You are doing the right thing.
But I tend to cheat a bit with non-entity classes. Like this:

Customer customer = new Customer(); // using customer as name as it is a
business-object

StringBuilder sb = new StringBuilder(); // using the short sb as it just a
simple stringbuilder
SqlCommand comm = new SqlCommand(); //using the shorter comm, as it is used
in a using-block


Being descriptive is important. Consider this:

List<Customer> list = new List<Customer>(); // bad. we know it is a list,
but a list of what?
List<Customer> customerList = new List<Customer>(); //better. while we now
know it is customers, it is redundant to append list to the name



Only in examples. If you code with those name in production-code, you should
be taken out and shot! =)
Also, calling a string 'str' or anything 'temp' should be criminal!
Click to expand...
I do not use such names as 'foo' and i never saw it in other place
than
examples but temp or something like that , maybe wouldnt be such bad
-
because - I think - for some handy 'very local variables' it would be
good
to do not use a brain for hard work of inventing thousands of
meaningfull names which are de facto unnecesary - so man maybe
could beter use even a thousands of 'foo's - like i's in for loops -
it can reduce this thousands of useless names - personnaly i think
it maybe will be an relief to me tu use great amounts of such
identical short temp names and be free from inventing a gret amounts
descriptive names and thinking about them. I am not sure to
this because I do not tried and I am programming not so very long
time to work out some rules yet.

There also I can add are days where I am tired of programming in work
(like this day
today) and I seem to myself I am almost hoples in it :( other days are
better, but
maybe today I am a little oversick of programming ( I try to help
myself by
understand things but feel genarally bad - also this usenet interface
by google - i do not like - gets me very angry)

As to this example above with
a) list
b) consumerList
c) consumers
I probably will be trying not to include type information in names
cause
probably it is a good rule but as first look maybe the b) or even a)
may seem for some people like myself maybe to be better than c
because I think it is easier to think when you program about
'list' than about 'consumers' becouse probaby maybe for mind
is to easier thinking about real (concrete) list and operations
I can do on it than the abstract consumers.
With VS 2005 and 2007 you get great refactoring support.
Makes it easy and safe to change names, why you don't have to be so
definitive when you name stuff.


Happy Coding
- Michael S
Click to expand...

bye
K.
 
Koliber, my apologies, just realised I mis-spelt you name in my previous
post.

Dave
 
Koliber, my apologies, just realised I mis-spelt you name in my previous
post.

Dave
Click to expand...

Not a problem at all :) Dave Shooter
My nickname (or moniker) is of not of an special importance
my association which caused me to choice this one here
is a little foggy or blur for me. Koliber means 'humming bird' but
it is better that not I am the koliber but maybe it is coaligned
with
some vision of such bird. Coliber can alco associate witch some co'
liber'
maybe and I tryin to be co'liber be hero and gentleman of liberty

(but feelin here all time a little weird in english language)
K.
 
Back
Top