Top 25 kodefejl du ikke skal lave

krainert (3) skrev:

men der er vel intet i vejen med anvendelsen af queries direkte, så længe brugerens input først gennemtjekkes og kritiske karakterer escapes - eller hvad?

Windcape (4) skrev:

Stored Procedures er heldigvis ved at dø still ud. Og tak for det, så slipper man for at have en DBA ansat. ORM er en meget bedre løsning.

arne_v (6) skrev:

Men bemærk at stored procedures i teorien godt kan kaldes uden brug af parameters og dermed være sårbare overfor SQL injection.

c03 (7) skrev:

#5
ja.. eller lære at programmere? selvfølgelig kan man lave fejl, men jeg stopper jo ik med at køre bil fordi der er andre der kører galt =)

arne_v (10) skrev:

SP'ere er ikke ved at uddø.

arne_v (10) skrev:

ORM er godt men ikke til alle formål.

ghostface (9) skrev:

Ud over at beskytte din database ultimativt (ved fx. kun at give adgang til at eksekvere Stored Procedures og ikke selv lave queries) så betyder det også at alle apps og websites der bruger en given procedure vil blive opdateret når den ændres på databasen

Windcape (11) skrev:

Afhænger det ikke af databasen? Jeg kender ikke nogen måde at definere Stored Procedures i MS SQL uden at angive type.

using System;
using System.Data;
using System.Data.SqlClient;

namespace E
{
public class Program
{
public static void Test(string par)
{
using(SqlConnection con = new SqlConnection(@"Server=ARNEPC3\SQLEXPRESS;Integrated Security=SSPI;Database=Test"))
{
con.Open();
SqlCommand q = new SqlCommand("SP_TABLES " + par, con);
SqlDataReader rdr = q.ExecuteReader();
while(rdr.Read())
{
Console.WriteLine(rdr[0] + "." + rdr[1] + "." + rdr[2]);
}
}
}
public static void Main(string[] args)
{
// lidt setup
using(SqlConnection con = new SqlConnection(@"Server=ARNEPC3\SQLEXPRESS;Integrated Security=SSPI;Database=Test"))
{
con.Open();
SqlCommand cre = new SqlCommand("CREATE TABLE supervigtig (id INTEGER IDENTITY PRIMARY KEY, txt VARCHAR(50))", con);
cre.ExecuteNonQuery();
}
// lidt sjov
Console.WriteLine("As intended:");
Test("NULL, DBO");
Console.WriteLine("SQL injection:");
Test("NULL, DBO; DROP TABLE supervigtig");
Console.WriteLine("Verification:");
Test("NULL, DBO");
Console.ReadKey();
}
}
}

Windcape (11) skrev:

Nyere managed sprog med typecheck, overflow checks, exceptions etc. er måske langsommere til den promille af programmer som kræver superhøj hastighed (som f.eks. spil), men til det meste software, så er det bedre at bruge sprog som Java/C#, fordi at man sikre sig imod visse ting.

Windcape (12) skrev:

I webapplications er de ihvertfald ved at udgøre en forsvindende mængde i nyere projekter (legacy software tæller ikke!)

Windcape (12) skrev:

Rigtigt nok, men often har jeg set folk har brugt f.eks. Stored Procedures, hvor ORM havde været mere en optimal løsning.

Målet var i begge tilfælde at fjerne direkte SQL kald fra ens kode / business logic.

Windcape (14) skrev:

Problemet med dette har jo så været at faktisk få lavet den ændring.

Kode kan ændres og testes i et test miljø, hvor databasen typisk kun findes i et produktionsmiljø, og derfor skal ændres i real-time.

Hvis man har muligheden for at lukke ned om natten og lave ændringer, er det nok ikke et så stort problem. Men der er altså mange systemer i dag hvor du ikke har den mulighed!

Windcape (14) skrev:

Kode kan ændres og testes i et test miljø, hvor databasen typisk kun findes i et produktionsmiljø, og derfor skal ændres i real-time.

mgX (23) skrev:

lock(this);

KS (22) skrev:

intet nyt på den liste....de samme ting som har været på listen de sidste 15år......

myplacedk (24) skrev:

De der "halve" testmiljøer (hvor man bruger produktions-databasen) har jeg kun set hos amatører, som prøver at finde ud af hvad et testmiljø er, og stadig er langt fra målet.

røvskæg (25) skrev:

Er der backup på newz ?'; DROP TABLE forum;

Windcape (29) skrev:

"amatører" er vist et begreb som kan dække over alle virksomheder der ikke laver mission critical systemer (som f.eks. Bankerne).

arne_v (31) skrev:

Jeg vil tro at de fleste bare lidt større administrative systemer.

Statement stmt = con.createStatement();
stmt.executeUpdate("INSERT INTO t VALUES('" + s1 + "','" + s2 + "')");

PreparedStatement pstmt = con.prepareStatement("INSERT INTO t VALUES(?,?)");
pstmt.setString(1, s1);
pstmt.setString(2, s2);
pstmt.executeUpdate();

PreparedStatement pstmt = con.prepareStatement("INSERT INTO t VALUES('" + s1 + "','" + s2 + "')");
pstmt.executeUpdate();

Windcape (32) skrev:

Umiddelbart har jeg dog mødt flere udviklere hvor test ikke er normal procedure, end jeg har mødt dem hvor det er standard.

Windcape (35) skrev:

Er der virkelig udviklere som hader prepared statements så meget at de ikke vil gøre det rigtigt?

myplacedk (36) skrev:

Jeg kan ikke mindes faktisk at have mødt en udvikler*, som ikke synes det er naturligt at teste inden man sætter det i produktion.

Windcape (38) skrev:

Du er vist heller ikke typen som snakker med andre udviklere på irc og forums hele natten lang

Windcape (38) skrev:

(og ja, folk på IRC har også jobs, så det er ikke tilfældige amatører som snakker om deres hobbyprojekter).

Windcape (39) skrev:

Mange af de virksomheder folk arbejder hos har ringe/ingen test procedurer.

Windcape (39) skrev:

Men fra unit tests, til et rigtigt test miljø, build server, og nightly builds, der er lang vej

myplacedk (41) skrev:

Jojo. Men hvis de spørger om hjælp på IRC, så er projektet nok ikke så pokkers meget over hobbyniveau. Normalt ville man vel spørge en kollega. ;-)

Windcape (35) skrev:

Er der virkelig udviklere som hader prepared statements så meget at de ikke vil gøre det rigtigt?

Windcape (39) skrev:

Og hvis vi skal have "real life" erfaringer, kunne vi jo tage min årgang som pt. skriver speciale. Mange af de virksomheder folk arbejder hos har ringe/ingen test procedurer.

Det afhænger af teknologien, specielt i afdelinger der arbejder med web er test et ukendt begreb, hvor det er mere standardiseret andre steder i form af unit tests.

Men fra unit tests, til et rigtigt test miljø, build server, og nightly builds, der er lang vej, og det er langt fra alle virksomheder som gør i det (min erfaring er det modsatte).

Windcape (39) skrev:

Følgende checkliste burde implementeres http://www.codinghorror.com/blog/2006/04/are-you-f...

Zagadka (42) skrev:

Desværre kan der være performance problemer med at bruge prepared statements til alt, for at klargøre et sådant og derefter eksekvere det kan nemt tage længere tid at bruge et query direkte.

Zagadka (42) skrev:

Som en service til dem der bruger Java kan tilføjes at et PreparedStatement objekt skal lukkes med close() metoden ellers får du en memory leak af dimensioner. Min gamle kode havde en leak på 1 GB/uge.

An application calls the method Connection.close to indicate that it has finished
using a connection. All Statement objects created from a given Connection object
will be closed when the close method for the object is called.

All Statement objects will be closed when the connection
that created them is closed.

These comments about closing Statement objects apply to PreparedStatement
and CallableStatement objects as well.

However, it is good coding practice for applications to
close statements as soon as they have finished processing them. This allows any
external resources that the statement is using to be released immediately.