 | |
#1
 
| |||
| |||
|
Long column names...Performance issues? -
11-19-2008
, 11:29 AM
#2
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#3
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#4
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#5
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#6
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#7
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#8
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#9
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
#10
| |||
| |||
|
|
My group is working to create a new set of Db standards as we embark upon redesigning our new web app backend db. The other architect wants every table/column/variable name to be unabbreviated and as descriptive as possible. This of course leads to long and ungainly names. while this is all well and fine in theory, when writing a lot of code, long column names are no fun and often lead to bugs due to spelling errors (Not that I would know anything about that ) I would like to hear from the community what you all feel are best practices regarding naming conventions, and how they affect your environment. Thanks in advance! |
In my experience, naming debates can be a psychological pain in the
behind. (It could just be me tho.) What I like to do is make my naming
modular going from left to right so that the names sort but thats just
sort of a tiebreaker for me. Obviously the most important names in any
programming project are going to be the more public interfaces, like
modules that get referenced in many other modules, these are the ones
you want to name carefully if you can.
Long names would probably only impact performance slightly if your sql
is dynamically created and even then I don't see that names would be
so big that they'd even be a minute percentage of your performance
concerns. Since most sql is going to be compiled internally in your
sql server to be essentially numerically indexed objects, the actual
impact of naming is going to be in the self documenting nature of your
code and in that case its not so much the length of the names, its the
quality. On the other hand, you can get stuck psychologically trying
to find the best name for some wierd self referential variables that
are difficult to name because they have no non computer equivalent or
are incidental to the actual problem domain.
I remember one coder used to name his variables after random star trek
characters and episodes.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.