Welcome Guest, Not a member yet? Register   Sign In
Code Convention - Functions / Arrays etc.
#1

[eluser]PrivateSniper[/eluser]
Hey all, i've recently been designing a few sites in CI and love it - I have a question on convention and looking for advice to help me solve my current dilemma (I appreciate the answer could be personal preference also).

I am developing an application for a roulette app and it has tables of results and various data such as which column, red black green, etc. currently the db only holds the number and the rest of the 'magic' happens in code.

I know I could also do this in DB or with an array or functions, does anyone have any advice on which is better (I assume not the DB for speed).


One thought I had was to create a multi-dimension array for each number ie
Code:
$numbers = array(
"0" => array(
      'color' => 'green'
      'row' => '0'
etc.

The way i'm currently doing it and it's starting to feel un-managable is having a function for each ie
Code:
function number_to_color($number)
{
// code
}
function number_to_row($number)
{
// code
}

The above in itself is fine but I now need to compare ie the current results color against the previous results color, for about 10-15 columns of data and i'm thinking getting the result and running the same 10 functions again is wasteful?

Thanks in advance for any suggestions/thoughts <3
#2

[eluser]boltsabre[/eluser]
Sorry if I missed it in your post, but what is "row"? Is that just the number? Or is it something else? I'm not real familiar with roulette...

Apart from 0 (green), it's 1 = red, 2 = black, 3 = red, 4 = black.... (or colours reversed, it doesn't matter, but it's a constant iterating "thing" isn't it? There are no 2 concurrent numbers can be the same colour???). If so, look into the php comparission operator % modulus, it could be exactly what you're after!

http://php.net/manual/en/language.operat...hmetic.php

Code:
function number_to_color($number){
    if ($number == 0) return 'green';
   elseif($number % 2 == 0) return 'black';
   else return 'red';
}

Personally, I think for such a small application like this, you could run this function 1,000+ times on your server without the user noticing anything major in terms of page load / lag... but you could do some testing to be safe.
#3

[eluser]TheFuzzy0ne[/eluser]
I agree with boltsabre. If you need to run a function more than once, run it as many times as necessary, just keep an eye on performance, and remember to keep scalability in mind. In this instance, since you have finite number of times you're going to need to call these functions, I don't think it will be an issue.

However, is there any reason you can't keep the calculated rows in the database? Perhaps use an ENUM field for colour.

It may also be an indication that you need to look at your database design again, and use some joins to pull the data out in the format you want.

I've never been one for Roulette, so I'm not entirely sure how it works and what's involved.

I'm intrigued, and I'd appreciate it if you could give more details on how Roulette works with regards to colours and rows, or link to some kind of resource that will explain it all.
#4

[eluser]PrivateSniper[/eluser]
Thanks to both for your replies.

Red/Black isn't a straight forward odd/even so i've used arrays and this has been fine, it's more things like side bets etc that have the more complex code but i've just put them into a series of functions.

Here is a picture of a typical roulette board showing some of the bets http://bit.ly/10fRCz2 - there's probably hundereds of different combo's that people play so the site i'm making is to help people keep track of stuff like this Wink

With regards to your comments on the database - I think like you mentioned pulling the line from the DB or a lightweight function maybe wont be too much of a comparison in terms of performance so I think i'm ok on this front.

(ps I also dont know a great deal about roulette, just enough to know i'm crap at playing it lol) Smile

I suppose my question was more code than situational ie is
Code:
$number['0']['color']
better than
Code:
$color = $this->Roulette_model->get_color($number);
in terms of readability/development
#5

[eluser]TheFuzzy0ne[/eluser]
How would you obtain that array to begin with? I assumed you would iterate through your results and build an array using those helper methods?

My suggestion to you would be to go with whatever makes sense, and don't second-guess yourself. I do that all the time, and it causes me loads frustration. I can easily sit picking a problem to pieces for hours on end, making it more and more complex. Now I just go about it in the simplest way I can, and then refactor my code to improve performance, whilst maintaining readability and structure.

I have many models, similar to yours, which format various components as they are output through my views. I think it's safe to say that there are at least 10 calls to different helper methods per result, and I'm outputting 50 rows per page. That's 500 calls, and the page still generates in less than 0.1 seconds.

Profiling your code is the key. You can find the bottlenecks and see if you can optimise them.

I prefer using helper methods, because it can cut down on all the extra logic within your views, and the methods can be reused anywhere else. For example, in my member model, I have a format_date_of_birth() method in my member model:
Code:
function format_date_of_birth($member, $default='N/A')
{
    if (isset($member['date_of_birth']))
    {
        return date($this->date_format, strtotime($member['date_of_birth']));
    }

    return $default;
}

If this logic was in your view, not only would it make your view more complex than necessary, but if you used the same logic in multiple views, and then decided to change it, you'd have to change it in all of them. In this instance (for the format of the date, at least), I only have to change it in one place, and that will change it everywhere else.

I'm not saying this is the "best" way to do it, but it seems to work, and saves those ugly "undefined index" errors.
#6

[eluser]PrivateSniper[/eluser]
Good advice thanks, yes the array I was thinking would have been hand coded but I think i'll stick with the functions at least for now, like you say I can keep an eye on how it's performing Smile
#7

[eluser]Aken[/eluser]
If you're interested in statistics, specifically looking up stuff from your database directly, not necessary from your web application, you should have each number's information in the database. You can have columns for number, color, row, etc. The problem with doing it the way you are now is that you can't retrieve results based on things like color or row, because either A) you have to retrieve every bet and then get only the ones you want, or B) you have to create a list of the numbers that are in the set you want to retrieve, and then query based on that. So DB interactions are going to become a real hassle at some point.

Requiring a function for testing whether a number is a certain color or row seems really pointless. If you have that data already stacked in an array, sorted by the number, all you'd really need to do is something like this:

Code:
$numbers['12']['color']; // red
$numbers['12']['row']; // 4
$numbers['12']['odd']; // false

You can generate this array either by hand, or by pulling the DB info (I would pull from the DB, so you only have one central place to make changes if needed).
#8

[eluser]PrivateSniper[/eluser]
@Aken
That's along the lines of what I was thinking. I think i'll stick to the way i'm going for now till app functionality is 'complete' then perhaps look at this while I refactor, thanks
#9

[eluser]Aken[/eluser]
Why develop poorly now? If you're planning on revamping it later, just do it now. Less work, better product.
#10

[eluser]PrivateSniper[/eluser]
True enough, I guess i'm just not sure on which way would be better, my main reason for asking the question was to see if there's a clear 'winner' in terms of what community developers would prefer to see (incase anyone has to continue development of my app in the future). It's an app I need a quick turnaround for at least in terms of functionality, but I would then have the luxury of being able to modify as I go Smile




Theme © iAndrew 2016 - Forum software by © MyBB