Ah, a C guy. That explains so much.
Having programming experience is great, but don't take that knowledge and try to fit it into the PHP paradigm. Square peg, round hole. Learning PHP is about more than just syntax and function names - you have to learn how to write PHP code too. How the language works, what it can and cannot do, and the best way(s) it provides to accomplish a goal. The knowledge you should be carrying over is about code
theory, not code
implementation.
C doesn't really have any good mechanism for indicating various forms of failure. No exceptions, no classes. You call a function, it returns a value (and maybe has a few pointers for output parameters). That's all you have to work with. Actually, to be more precise, that's
the C paradigm: you could use structs, or arrays, or another structure, but it cuts into efficiency and performance. And C is big on efficiency.
PHP, being a higher-level language, is not like that. Efficiency is good, of course, but the most important aspect of PHP code is its maintainability; over-optimization will hurt you in the long run. It has exceptions you can use to interrupt program flow for "exceptional" circumstances, and it has classes where you can bundle together data and behavior into a single cohesive unit. The PHP paradigm is about writing descriptive and hopefully self-documenting code.
As for the Unix philosophy, that's cool and all but remember that it's not programming philosophy. There are certain beneficial aspects like its separation of concerns, but not everything will be helpful with PHP.
Here's what I suggest: learn about the nature of PHP - like, go through the reference section of the manual. Learn about classes, interfaces, extensions, INI settings, exceptions, databases, resources... all the tools available to you as a PHP developer. Then consider what those tools can do to help you accomplish a goal. You need to switch your mentality from "how would I write this in C and translate it into PHP" to "how would I write this natively in PHP".
Giganitris wrote:
About return codes for functions, why not? The intended thing is that I write a documentation file that has the return codes at the very beginning, and it makes it much easier for a dev to write a file that includes mine. Or even if I provide a table in the comments, wouldn't that also work?
That's the C mentality. Set that aside.
What does PHP provide that is relevant here? The best answer is booleans and exceptions. If your function should return a simple yes or no for success then it can return true/false; if your function should generally work but sometimes there may be a problem then it can throw an exception. Let's set aside the "best way" to use exceptions and just stick with the base Exception class.
Take rmUser, which we'll now call "deleteUser" (remember: descriptive and self-documenting). For the most part it will delete a user successfully, but there are multiple circumstances where it might not succeed. As such the exception strategy is more appropriate than true/false.
In pseudocode:
Code:
function deleteUser($merits, $user) {
if user cannot delete then throw an Exception("Permission denied");
$sqlcon = singleFunctionToGetDatabaseConnection();
if attempt to delete user fails then throw an Exception("Failed to delete user");
// if we're here then everything was successful
// we don't need anything here to indicate success because that's obvious from a lack of thrown exceptions
}
Since we're using exceptions, the poorly-named "singleFunctionToGetDatabaseConnection" (
too descriptive) could throw its own exception if it fails to connect - that's another example of "should generally work" code.
Exceptions require a bit more code to work their best: try/catch blocks.
Code:
try {
deleteUser($merits, $user);
indicate success
} catch (Exception $e) {
indicate failure // exception message is $e->getMessage()
}
Without a try/catch any exception that is thrown will cause the script to abort; to borrow C terminology, exceptions are like longjumps to the closest try/catch block, and no block in the call stack means a crash.
Does that make sense?
Giganitris wrote:
What are the harmful things an SQL error can contain?
If there is a syntax error in a MySQL query, like
Code:
DELETE FROM users WHER user='$e_user'
then the error message will look like
Quote:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHER user='Giganitris'' at line 1
That is, it contains a portion of the query itself starting at the location of the syntax error. For this query it's not much of a problem, but if you put password hashes or secret keys or other information that needs to be kept from the user, they may be able to see it in the error message.
Giganitris wrote:
Haha I'm sorry about the "snippets" thing. This is the only file that'll contain SQL at all.
It's a pet peeve. Many people have a "snippets" or "shared code" file with stuff they've written and rewritten over the years, available so they can reuse it without having to write it yet again. Personally, I think it promotes
copy and paste programming, which is something I
really hate.
Giganitris wrote:
How do I separate the salt that's stored with the hash to verify the password, assuming I have to do it myself.?
You don't. It's one of the things that PHP does almost uniquely from every other language out there: hashes contain all the information necessary.
Consider a simple MD5 hash on a salted password. The algorithm itself will spit out a 128-bit string, which most people (including PHP) represent as a 32-hex-character string. That's the whole hash. To replicate that hash you need to know the original input and the salt... and the algorithm. Normally you would store the hash and salt separately, and simply program MD5 into your application, but PHP can combine them all together into one string in the form
Code:
$1$salt........hash............................
or more generically
Code:
'$' algorithm-identifier '$' specific-information-for-the-algorithm hash
Here, MD5 is represented by the identifier "1", the specific information is a salt is 12 characters long (other algorithms need more than just a salt), and the hash is 32 characters long.
(Why 12 for the salt? I don't know. But if you want to use the built-in mechanisms for this unified string thing then the salt needs to be that long. Which is fine.)
The most obvious benefit with this methods is that there is only one piece of data to manage, but there's another: you can use this exact string to duplicate a hash as well, as the string itself functions as a "salt" with the $1$ indicating the algorithm and only the first however-many characters (here, 12) being used for the actual salt to the algorithm.
What I've described is specific to
crypt and
password_hash. You can always "roll your own" using other functions.
Giganitris wrote:
A friend recommended PDO over mysqli, so I guess I might change it to that and rewrite my SQL to use prepared statements.
Good.
Giganitris wrote:
Also just a snippet of what the troll said "Apache2 is the most pwned bloatware of them all. You really are a skiddy."
"You can't even indent the code properly."
Please tell me I'm not a skiddy, that's the worst insult in all of software history. Seriously, I've been called a lot of horrible things, but that hurts the most.
He's a troll. Don't feed the troll.
You're not a skiddy. Your issue is not that you don't know what you're doing, but that you know what you're doing in one language and trying to apply it to another. On top of that you're still learning PHP. Obviously you're not going to be best coder around - what matters is how you proceed from here.