Writing good code, solving problems.
Hi.
Reading code off the internet sometimes triggers me. I immediately start thinking: "hmm, why didn't you that, or that?". (I'm not trying to be that smartass or anything, and I'm by any means not the best, just wanted to make things a little clearer, okay, good). Before we dive in, when writing something, always ask yourself these questions: - What do I want to know? - What do I already know? Trust me, it's extremely helpful. Here're a couple of dilemmas with examples, and more compact solutions: 1. A guy named Jerry wants a specific command to output the client's team. This is how he did it:
Spoiler
Now, this code is perfectly fine, but. We can shorten it... a lot:
Spoiler
2. This one day I was writing a stats plugin and there was this one command that was supposed to create a menu, showing you the top players on the server, based different categories. Here's how I first did it:
Spoiler
And this too is just fine, but, we can be even more efficient with our lines, and here's the solution I found:
Spoiler
I believe that programming isn't just about making things work, it's about making it nice aswell. With that being said, you can almost always make your code just a little bit better. (Also, I don't even know if this page is useful, but, meh). |
Re: Writing good code, solving problems.
Won't it be like this? Correct me if I'm wrong ._.
PHP Code:
|
Re: Writing good code, solving problems.
Quote:
|
Re: Writing good code, solving problems.
NULL_STRING has an undefined value, so you can't depend on it being an empty string. Better use an empty string "" right away!
|
Re: Writing good code, solving problems.
Quote:
|
Re: Writing good code, solving problems.
Quote:
like in the first example. The ternary operator: PHP Code:
|
Re: Writing good code, solving problems.
Code:
PrintToChat(iClient, "Yay, you're in the %sTerrorist team!", iTeam == 3 ? "Counter-" : "");Additionally, Menu_Top_Menu_Handler is in poor form -- the third parameter is not always going to be a client index, per the MenuAction documentation. You've gated off MenuAction_End, where the parameter in question is the MenuEnd reason, and so you're now always leaking handles (because the values that you think are clients are either 0 or negative). That said, I'd also take that approach to simplifying the query setup. As far as clear code goes, I'm a fan of "Avoid Else, Return Early" to keep indentation to a minimum, but that's mostly a matter of opinion and not a strict style to adhere to. |
| All times are GMT -4. The time now is 23:30. |
Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.