In the case of cfinsert and cfupdate for the same reason I avoided
cfform for a long time... they suck... I do however have a pair of
intelligent alternatives to cfinsert/cfupdate which:
1) allow the use of structures other than FORM to pass in data
2) don't attempt to insert columns which don't e
Except that's 2 places... 1 in the database and 1 in the code... 2...
:)
I wouldn't call that lazy -- you'd be _amazed_ how much time you can
save (and productivity you can gain) by cutting out very small
(microscopic) tasks which occur often. At least for me, I consider
schema changes at least in
Funny I was going to use DAO as an arguement for using Select * but
didn't bother since I didn;t want to mix entry level using select *
with using Select * with a DAO Design Pattern which if you are using
DAO you're not entry level. I could just as Easily say though (just
for arguements sake) that
Though in a DAO situation there's little point in not selecting *
since the DAO generally is just going to get all the columns for a
specific record and drop them into the bean or other object
properties. You can of course argue that explicitly declaring the
columns is faster for the database (alth
there is no need at all to lock anything. Once you get the nextval from the
sequence, it is yours to keep. Another thread, request, user what have you
will get a differnt value guarnteed.
You will have to use two queries to return the value though, but again, no
locking is needed.
DK
On 5/12
Which still does not return the unique identifier(the value of
SEQNAME.NEXTVAL) to the CFM page. The lack of returning a the unique
identifier was one of the big hang ups given against CFINSERT. A simple
trigger in the database and making sure form fields use the same names as
columns would mak
It is SEQNAME.NEXTVAL in Oracle and I'd like to see how you get that to work
in a single CFQUERY that returns NEWID to the CFM page. Using two CFQUERies
would at least avoid the need to "lock" anything.
On 5/12/05, Douglas Knudsen <[EMAIL PROTECTED]> wrote:
>
> with oracle vernacular the word
Original Message-
From: Douglas Knudsen [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 12, 2005 10:00 AM
To: CF-Jobs-Talk
....Subject: Re: What makes a programmer look low level
with oracle vernacular the word is sequence. Just perform a query to
return
the next v
with oracle vernacular the word is sequence. Just perform a query to return
the next value in the sequence, then use it in your inserts.
SELECT seqname.next_val as newid FROM dual
INSERT INTO tablefoo (id, goo) VALUES (newid, 'soem stuff')
DK
On 5/12/05, Aaron Rouse <[EMAIL PROTECTED]> wrote:
At 09:18 AM 5/12/2005, you wrote:
> CFLOCKing two queries together? Wouldn't that be CFTRANSACTIONing the two
>queries together?
Well, the examples given with the select max(id) are so ugly, don't even
consider doing it, but since it's in at least one of the CF books a lot of
developers got set
That syntax is not even valid for all databases. An example I am thinking of
is how to return the identity when using Oracle. I know the syntax to use if
just in a SQL client, tried it with a couple of versions of DB drivers with
CF and never had it work. Of course it could simple just be done w
At 09:12 AM 5/12/2005, you wrote:
>At 09:00 AM 5/12/2005, you wrote:
> >CFQUERY will not return back a new identity either, well depending on the
> >database chosen it will not without a second cfquery.
>
>
>This has sometimes worked in the past:
>
>declare @new_id INT
>insert into table (a, b)
>va
At 09:00 AM 5/12/2005, you wrote:
>CFQUERY will not return back a new identity either, well depending on the
>database chosen it will not without a second cfquery.
This has sometimes worked in the past:
declare @new_id INT
insert into table (a, b)
values ('#a#', '#b#'
select @new_id as new_id
I
CFQUERY will not return back a new identity either, well depending on the
database chosen it will not without a second cfquery. Just curious, not
implying anything wrong with it one bit, but what are your reasonings for
using almost all SPs for your DB work? Also curious the reasons for that
si
At 07:35 AM 5/12/2005, you wrote:
>OK, I'll bite. Why would you *not* use standard CFML tags for the
>purpose they fullfill?
Well, for one thing, because CFINSERT and CFUPDATE don't call stored procs
and we do almost all our db work via stored procs.
With CFQUERY you can do CFQUERYPARAM to help
Damien McKenna wrote:
> OK, I'll bite. Why would you *not* use standard CFML tags for the
> purpose they fullfill?
Jim's already explained one reason to not use cfinsert/cfupdate
(variable names having to match). Another reason is that writing your
own queries gives you more control over the q
Glenn Saunders wrote:
> But for most CF applications, that degree of optimization is overkill in
> comparison to the extra keystrokes it takes to do variables. I find this
> code:
>
>
>
>
>
>
>
> much harder to read than
>
>
>
>
>
>
I typically don't bother using "variables." when
CFINSERT and CFUPDATE are nice shortcuts, but they're wierd. You're
required to have your variable names match the exact column names in the
DB, which, unless you have planned for that from the beginning, almost
always requires you to write unnecessary code to get everything in order before ca
OK, I'll bite. Why would you *not* use standard CFML tags for the
purpose they fullfill?
--
Damien McKenna - Web Developer - [EMAIL PROTECTED]
The Limu Company - http://www.thelimucompany.com/ - 407-804-1014
#include
> -Original Message-
> From: Glenn Saunders [mailto:[EMAIL PROTECTE
I guess we all have our admamant areas :) If I see a Select * I get
fairly upset with the developer. In most caees you are bringing back
unneeded data and in a large developement envirmoent another programer
can not easily step into the code and see what is being selected from
where.
Adam H
On 5
Thursday, May 12, 2005 11:02 AM
Subject: Re: What makes a programmer look low level
> At 01:10 PM 5/9/2005, you wrote:
> >Like I said I knew people would disagree, and I understand that which
> >is why I scope everything b/c I dislike being a black sheep :) But
> >I'll ask
At 01:52 PM 5/9/2005, you wrote:
>Is it just me, or do the comments other developers leave throughout their
>code mostly get in the way of just reading the raw code? Having read through
>all kinds of existing code, I much prefer to have everything scoped and the
>code arranged in a consistent, logi
At 01:14 PM 5/9/2005, you wrote:
>That reminds me of one...Select * in SQL statements...thats a really
>big PITA and a sign of a beginner or a lazy coder...
I guess that would make me a lazy coder.
I don't think this is always the case if your application is evolving a lot.
Remember, you never r
At 01:11 PM 5/9/2005, you wrote:
>along with -- up until now --
>cfform.
What do you have against CFFORM?
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting h
At 01:10 PM 5/9/2005, you wrote:
>Like I said I knew people would disagree, and I understand that which
>is why I scope everything b/c I dislike being a black sheep :) But
>I'll ask why are people so adamant about it?
Because CF has to interrogate memory on unscoped variables based on a
predefine
At 12:55 PM 5/9/2005, you wrote:
>So me scoping myQuery.varname is essential in a query="myQuery"> block? I disagree but I know people think
I never do that unless there is a variable name collision, which I then try
to avoid anyway.
I also sometimes don't use variables. just to avoid extra keys
At 11:14 AM 5/9/2005, you wrote:
> > good: mycart[1].productname
> > good: mycart[1]["productname"]
> > bad: mycart[1][1] (not-descriptive)
> > bad: mycart[1][productname] (overcomplicated)
I have also seen cases of pseudoarrays that could be real arrays:
a_1
a_2
a_3
vs.
a[1]
a[2
These two I seem to never come across, do many people come across code using
them?
On 5/11/05, Glenn Saunders <[EMAIL PROTECTED]> wrote:
>
>
>
> I'm also not too fond of code that uses CFINSERT and CFUPDATE usage
> instead
> of calling a proc or doing it via cfquery.
>
>
>
~~
At 10:50 AM 5/9/2005, you wrote:
>I am sure you can, however I am referring to the blatantly obvious places it
>is not needed and does nothing more than slow down a page from loading. It
>shows that someone does not fully understand what I would consider basic SQL
>and CFM skills.
I'm also not too
At 10:47 AM 5/9/2005, you wrote:
>I can see places where this is needed
If the join is across servers, sure.
If the join was expensive enough and you were doing a paged view then you
could run one query per page with a valuelist of the foreign keys rather
than doing a round trip to the db on ev
At 10:33 AM 5/9/2005, you wrote:
I have met some developers that are very talented (I'd
>consider them "Senior" level developers based on skill alone) who happen
>to have poor syntax/code style habits.
Did you explain to them the right way to do it? If so, did they
change? If they didn't, that
Anyone can write udfs and custom tags it takes very little skill.
Writting well crafted ones might make you mid-level. Custom tags with
something like checking the execution mode missing definetly would
make you look low level...Likewise making a UDF isn't that complex but
not varing all your varia
If someone can write CFCs, custom tags and UDFs, I automatically upgrade
him/her to mid-level. For me this would be a sign that the person is a
mid-level developer.
Johnny
> Breaking encapsulation In CFCs (or custom tags or UDFs) by referencing
>shared scope variable (application, session, r
= majority;
> no OR bad documentation or comments = majority;
> *[good documentation or comments = yeah right;]
> -Original Message-
> From: Jeffry Houser [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 10, 2005 7:42 AM
> To: CF-Jobs-
right;]
-Original Message-
From: Jeffry Houser [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 7:42 AM
To: CF-Jobs-Talk
Subject: RE: What makes a programmer look low level
At 10:39 PM 5/9/2005, you wrote:
>Not all documentation is good; in fact, most is bad (in my experience.)
documentation or comments= yeah right;]
-Original Message-
From: Jeffry Houser [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 7:42 AM
To: CF-Jobs-Talk
Subject: SPAM-LOW: RE: What makes a programmer look low level
At 10:39 PM 5/9/2005, you wrote:
>Not all documentat
At 10:39 PM 5/9/2005, you wrote:
>Not all documentation is good; in fact, most is bad (in my experience.)
In my experience, most is non-existent. But, I've never had a problem
with documentation that is there. And I still have a hard time imagining a
time where comments make it hard to follo
Nah, they're just desperate :)
-Original Message-
From: Simon Horwith [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 6:55 PM
To: CF-Jobs-Talk
Subject: Re: What makes a programmer look low level
I agree. My point about having at least 3 years of experience wasn't
tha
fry Houser [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 7:18 PM
To: CF-Jobs-Talk
Subject: RE: What makes a programmer look low level
Good documentation should show you how it does work.
I find it hard to imagine a point where code documentation detracts from
code readability, which is
> 1. Not predefining variable for later use at
> start of code file or in a universal inclusion.
I'll disagree here and say this is a matter of style, not skill. This makes
sense to do in an environment where multiple developers will be working on
the same code-base all the time, but for smaller
it happens, is fantastic.
>
>Again, this is my experience with hiring that I'm speaking from.
>
>- Original Message -
>From: Simon Horwith <[EMAIL PROTECTED]>
>Date: Monday, May 9, 2005 3:26 pm
>Subject: Re: What makes a programmer look low level
>
>
>
&
y seeing what everything does and how its being
>done.
>
>
>
>-Original Message-
>From: Jeffry Houser [mailto:[EMAIL PROTECTED]
>Sent: Monday, May 09, 2005 5:07 PM
>To: CF-Jobs-Talk
>Subject: RE: What makes a programmer look low level
>
>
> When you say &
oping even is.
- Original Message -
From: Aaron Rouse <[EMAIL PROTECTED]>
Date: Monday, May 9, 2005 2:02 pm
Subject: Re: What makes a programmer look low level
> I tend to scope these, it is not out of worry of me not knowing
> what I am
> referencing or even of someone el
se
kinds of people, when it happens, is fantastic.
Again, this is my experience with hiring that I'm speaking from.
- Original Message -
From: Simon Horwith <[EMAIL PROTECTED]>
Date: Monday, May 9, 2005 3:26 pm
Subject: Re: What makes a programmer look low level
> no, i
> You can ask the applicant, ask a company the applicant has
> worked for, see if they have any open source projects,
> etc...
> I never have problems getting code samples from
> applicants, even code that's a few years old. Most people
> are quite proud of what they've worked on, regardless of
>
What I have seen some do is put URL and FORM into the REQUEST scope and then
reference that scope.
> On 5/9/05, Jeffry Houser <[EMAIL PROTECTED]> wrote:
> > If a page can be accessed via both "url requests" and "form posts" how
> > does one handle a variable that may be in either scope? Do ya'l
I generally put form and urls into a My structure. THen I do
my.variableName..but I suppose to appease some I should be doing
variables.my.variableName ;)
Adam H
On 5/9/05, Jeffry Houser <[EMAIL PROTECTED]> wrote:
> If a page can be accessed via both "url requests" and "form posts" how
> does
or running
through the lines and clearly seeing what everything does and how its being
done.
-Original Message-
From: Jeffry Houser [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 5:07 PM
To: CF-Jobs-Talk
Subject: RE: What makes a programmer look low level
When you say "Str
ars old. Most people are quite proud of what they've worked on,
>regardless of what someone else thinks of it.
>
>- Original Message -----
>From: Simon Horwith <[EMAIL PROTECTED]>
>Date: Monday, May 9, 2005 2:06 pm
>Subject: Re: What makes a programmer look low leve
ss of what someone else thinks of it.
- Original Message -
From: Simon Horwith <[EMAIL PROTECTED]>
Date: Monday, May 9, 2005 2:06 pm
Subject: Re: What makes a programmer look low level
> I'd love to know how ou "find" code that an applicant wrote 3
> years
> ag
When you say "Structure" are you talking about code formatting, or
something different? My impression is that you are referring to "code
formatting" however structure could mean different things, so...
I'd rather see comments than formatted code. I can read unformatted
code, or format it
I generally create a variable to hold the value - but I don't put it in
either of the possible originating scopes.
~Simon
Simon Horwith
CIO, AboutWeb - http://www.aboutweb.com
Editor-in-Chief, ColdFusion Developers Journal
Member of Team Macromedia
Macromedia Certified Master Instructor
Blog - h
http://www.logicsynthesis.com
-Original Message-
From: Adam Haskell [mailto:[EMAIL PROTECTED]
Sent: Monday, May 09, 2005 4:14 PM
To: CF-Jobs-Talk
Subject: Re: What makes a programmer look low level
That reminds me of one...Select * in SQL statements...thats a really
big PITA and a sign of a beginner or a
If a page can be accessed via both "url requests" and "form posts" how
does one handle a variable that may be in either scope? Do ya'll use a
"form2urlvariable" tag (like what used to be a part of fusebox ) or do you
use a different method?
This is the one place I can think of where not sc
I wonder how many of those apps are "legacy" apps built before CFCs that
were not re-written to take advantage of them.
At 04:26 PM 5/9/2005, you wrote:
>Taking the fact that 80% of the existing applications don't
>use CFCs at all
--
Jeffry Houser, Web Developer, Writer, Songwriter, Recording
In this situtation I would not argue that scoping is a good
idea...ecspecially with the quark of #colmn_and_variables_var# vs
. I have apersonal petpeeve
about having variable names that are the same...so I don;t think about
it in that respect.
I suppose it also depends on the size of your code blo
How would you spot these in a code sample? :P
> 1. An unwillingness to learn
> 2. Believing that they have no room for improvement
> 3. Blindly following the advice of some so-called
> Credible Person
> - Original Message -
> From: [EMAIL PROTECTED] (Michael Dinowitz)
> Date: Monday, M
Adam Haskell wrote:
> I think scoping variables makes code easier to read but to me scoping
> every single vaible tells me you either 1) don;t trust your code or 2)
> don't understand how scope is working in your current situation which
> would imply a lower level of skill. I know most poeple will
I've seen pages that reference a variable like "#user_id#" inside and
outside of a query loop - and the page accepts a url parameter and form
field with this name AS WELL as having a query containing a column with
that name. Not specifying where the variable came from makes the code
much more
I agree that if we're generalizing, any developer that doesn't
encapslate code is a poor developer (novice or otherwise) but CF, as you
say, has many "developers" that aren't developers by trade at all. CF
Applications are often times so simple that to call them an
"application" may seem like
If this is a matter of finding the right candidate, I'd be most interested in
what they have done. How many projects? Where are the projects online to run
through the paces? How similar is anything they have done to anything you are
doing? Are they familiar with your industry? With your clients?
That reminds me of one...Select * in SQL statements...thats a really
big PITA and a sign of a beginner or a lazy coder...
I completely understand readability but I would like to think my
comments will help even the novice of developers understand where my
variables are...but I see that...and thats
> Oh yeah I forgot another short sighted new programmer
> annoyance I hold is:
> Complex code that isn't tabbed or seperated like in case
> of a query with 100 fields running a big comma list versus
> putting a carriage return after each field name follwed by
> a comma.
> Makes debugging a pain s
Like I said I knew people would disagree, and I understand that which
is why I scope everything b/c I dislike being a black sheep :) But
I'll ask why are people so adamant about it?
Adam H
On 5/9/05, Simon Horwith <[EMAIL PROTECTED]> wrote:
> not only do I adamantly believe that inside of a "CFO
> -Original Message-
> From: Simon Horwith [mailto:[EMAIL PROTECTED]
>
> I'd love to know how ou "find" code that an applicant wrote 3 years
> ago.
Contributions to OSS?
--
Damien McKenna - Web Developer - [EMAIL PROTECTED]
The Limu Company - http://www.thelimucompany.com/ - 407-804-1
Code encapsulation is CS101 concept. If someone is not understanding
encapsulation, then they are a novice programmer.
Whether they are a novice CF Developer or not may be open to
interpretation, since many CF Developers are not programmers by trade.
At 03:50 PM 5/9/2005, you wrote:
>I wou
> What makes a programmer look low level is:
> 1. Not predefining variable for later use at start of code
> file or in a universal inclusion. Really, I think people
> should be held accountable to write out in documentation
> every variable used along with every set of data whether
> originating i
y wrote recently. Use brain to determine how much they've learned.
>
>- Original Message -
>From: "S. Isaac Dealey" <[EMAIL PROTECTED]>
>Date: Monday, May 9, 2005 1:32 pm
>Subject: Re: What makes a programmer look low level
>
>
>
>>How
Oh yeah I forgot another short sighted new programmer annoyance I hold is:
Complex code that isn't tabbed or seperated like in case of a query with 100
fields running a big comma list versus putting a carriage return after each
field name follwed by a comma.
Makes debugging a pain since you hav
I tend to scope these, it is not out of worry of me not knowing what I am
referencing or even of someone else coming in and not knowing. I think it is
more of just out of habbit and it just gets typed. I do know at one time I
came across a prior developers work who would be in a and they would
Easy. You find some code they wrote three years ago. Then you find some code
they wrote recently. Use brain to determine how much they've learned.
- Original Message -
From: "S. Isaac Dealey" <[EMAIL PROTECTED]>
Date: Monday, May 9, 2005 1:32 pm
Subject: Re: Wh
not only do I adamantly believe that inside of a "CFOUTPUT query=" loop
should you prefix the column names with the query name, but I also scope
the variable (cfoutput query="variables.qMyQuery".).
~Simon
Simon Horwith
CIO, AboutWeb - http://www.aboutweb.com
Editor-in-Chief, ColdFusion Deve
What makes a programmer look low level is:
1. Not predefining variable for later use at start of code file or in a
universal inclusion. Really, I think people should be held accountable to write
out in documentation every variable used along with every set of data whether
originating in a datab
So me scoping myQuery.varname is essential in a block? I disagree but I know people think
differently... I do agree with the url. or form. or cookie . though in
many cases it could be coming from different places so scoping those
are good. If you understand your current context you should not have
Nice! :) That one actually got a literal "laugh out loud" on this end.
:)
>>> How would you spot these in a code sample? :P
>
> - Jim
> S. Isaac Dealey wrote:
>>How would you spot these in a code sample? :P
>>
>>
>>>1. An unwillingness to learn
>>>2. Believing that they have no room for im
I wouldn't say that not scoping variables in CFCs or "breaking
encapsulation" by scoping variables in CFCs are traits of beginer
developers. The fact that a developer is using CFCs at all (unless
they're using them for all the wrong reasons) is a sign that they're not
a novice CF Developer.
I've got to disagree - I prefix every variable I reference and can only
fault those who don't. I think the reasons for this have already been
discussed.
~Simon
Simon Horwith
CIO, AboutWeb - http://www.aboutweb.com
Editor-in-Chief, ColdFusion Developers Journal
Member of Team Macromedia
Macromed
it's worth noting that none of these are easy to determine in an
interview. Some people are great developers who have poor interview
skills, which makes it entirely possible to mistake these qualities (or
lack thereof).
~Simon
Simon Horwith
CIO, AboutWeb - http://www.aboutweb.com
Editor-in-Chi
>> How would you spot these in a code sample? :P
- Jim
S. Isaac Dealey wrote:
>How would you spot these in a code sample? :P
>
>
>
>>1. An unwillingness to learn
>>2. Believing that they have no room for improvement
>>3. Blindly following the advice of some so-called
>>Credible Person
>>
I agree 100% on this, there have been countless times where I was trying to
determine where #blah# came from. Of course it does not help when dealing
with someones code who could have #blah# coming from 3-4 different scopes,
just all depends on which method they took to load up the page.
On 5/9
At 03:13 PM 5/9/2005, you wrote:
> > At 01:25 PM 5/9/2005, you wrote:
> >>How about we look at what makes a programmer look low
> >>level and work our
> >>way up. Two things that come right to mind are:
> >>1. Improper use of pound signs in evaluation zones
> >>2. Improper usage of IF clauses (not
> At 01:25 PM 5/9/2005, you wrote:
>>How about we look at what makes a programmer look low
>>level and work our
>>way up. Two things that come right to mind are:
>>1. Improper use of pound signs in evaluation zones
>>2. Improper usage of IF clauses (not using short circuited
>>Boolean evaluation)
Oh, speaking of cfif -- this also relates to copy-pasted code...
label
label
label
I see this frequently where the same block of code is repeated several
times to accomodate a series of conditional statements which could
easil
1. An unwillingness to learn
2. Believing that they have no room for improvement
3. Blindly following the advice of some so-called Credible Person
- Original Message -
From: [EMAIL PROTECTED] (Michael Dinowitz)
Date: Monday, May 9, 2005 11:25 am
Subject: What makes a programmer look low
I'd buy that.
I wanted to include something about JS/DOM, but in retrospect the only
people I know who really understand JS/DOM are at least
intermediate...
With the possible exception of understanding why it is that you can't
use JavaScript to set a CFML variable.
> I am sure you can, however
> Not scoping variables. Both, in regular templates (Is this a form
> variable, a URL variable, a local variable, etc.. ) and in Functions / CFCs
> (where improper scoping is more likely to have adverse side affects).
I think scoping variables makes code easier to read but to me scoping
every s
This could be purposely done and part of someones style. I always do the
method but have seen the other route taken from
rather knowledgable people. At what point do you decide it would be easier
to follow some nested if's over one single long if statement. I can not
really think of an example
> A lot of folks would argue about the pound signs saying that it's just
> a matter of preference. I certainly don't care to see pound signs
> where they're not needed -- it strikes me as sloppy
> and confusing, but I've never made a real issue of it.
That's why I said look. it's all about percept
At 01:25 PM 5/9/2005, you wrote:
>How about we look at what makes a programmer look low level and work our
>way up. Two things that come right to mind are:
>1. Improper use of pound signs in evaluation zones
>2. Improper usage of IF clauses (not using short circuited Boolean evaluation)
A few th
> 3. Queries inside of a cfloop or cfoutput (with the query
> attribute of
> course) and could have easily been avoided with a simple
> join in their
> original query.
> On 5/9/05, Michael Dinowitz <[EMAIL PROTECTED]>
> wrote:
>>
>> How about we look at what makes a programmer look low
>> level an
I am sure you can, however I am referring to the blatantly obvious places it
is not needed and does nothing more than slow down a page from loading. It
shows that someone does not fully understand what I would consider basic SQL
and CFM skills.
On 5/9/05, Michael Dinowitz <[EMAIL PROTECTED]> w
That's why I said "look" and not "are". :)
The point is when getting a job at a knowledgeable company, the way your
code looks is almost as important as what you know.
>I wouldn't use the term "low level" - "beginner level" or even
> "inexperienced" are more accurate descriptions and personal
I can see places where this is needed
> 3. Queries inside of a cfloop or cfoutput (with the query attribute of
> course) and could have easily been avoided with a simple join in their
> original query.
>
> On 5/9/05, Michael Dinowitz <[EMAIL PROTECTED]> wrote:
>>
>> How about we look at what make
Agree, low level reminds me of old assembly code :)
This is low level to me:
pushw
mov ax, dx
inc cx
stosw
etc...
Rizal
At 12:33 AM 5/10/2005, you wrote:
>I wouldn't use the term "low level" - "beginner level" or even
>"inexperienced" are more accurate descriptions and personally, I
>think t
I think it's the coding logic or algorithm that really matters...
Other than that: poor indentation, improper use of functions, queries, data
structure, session vars, etc.
Sure, it's nice to have a very clean and short code,
but there's a potential drawback in using that kind of code: low level
I wouldn't use the term "low level" - "beginner level" or even
"inexperienced" are more accurate descriptions and personally, I
think there are far too many possible signs. For that matter, I'd like
to mention that I have met some developers that are very talented (I'd
consider them "Senio
3. Queries inside of a cfloop or cfoutput (with the query attribute of
course) and could have easily been avoided with a simple join in their
original query.
On 5/9/05, Michael Dinowitz <[EMAIL PROTECTED]> wrote:
>
> How about we look at what makes a programmer look low level and work our
> w
97 matches
Mail list logo
