Review Request: Add Category and NewGame classes

Laszlo Papp djszapi at archlinux.us
Sat Jul 2 22:18:21 CEST 2011


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101816/#review4332
-----------------------------------------------------------


I completely agree about the order with Arjen. 

Yeah, I have also read that thread previously from Thiago. However I am not against the Q_PRIVATE_SLOTS either for now though, if we can just avoid a separate pimpl header file (*_p.h) that way. I am neutral on that topic for now.


player/lib/CMakeLists.txt
<http://git.reviewboard.kde.org/r/101816/#comment3593>

    It would be nice to make things as close as possible to the alphabetical order as the "ls" command lists the files in your directory.



player/lib/category.h
<http://git.reviewboard.kde.org/r/101816/#comment3594>

    Reverse order



player/lib/category.h
<http://git.reviewboard.kde.org/r/101816/#comment3595>

    No need for explicit in this case



player/lib/category.h
<http://git.reviewboard.kde.org/r/101816/#comment3619>

    Match these signals names according to the proposed ones below



player/lib/category.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3596>

    Separate lines



player/lib/category.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3597>

    Separate lines for the readability as well



player/lib/category.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3598>

    const ref as I corrected it a few times ;)



player/lib/category.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3599>

    I would personally use categoryFetchFinished



player/lib/category.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3600>

    I would personally use categoryFetchFailed accordingly



player/lib/remotegame.h
<http://git.reviewboard.kde.org/r/101816/#comment3601>

    Wrong order



player/lib/remotegame.h
<http://git.reviewboard.kde.org/r/101816/#comment3602>

    No need for explicit in these cases



player/lib/remotegame.h
<http://git.reviewboard.kde.org/r/101816/#comment3603>

    I would call it "startFetchExistingGame". -ing twice sounds a bit weird =)



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3604>

    Separate lines



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3605>

    Separate lines



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3606>

    I would use "fetchExistingGameFinished".
    
    Also, you missed emitting the signal there actually which is a bigger issue than the term.



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3607>

    I think you confused it with the other method. I would call it anyway "fetchExistingGameFailed"



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3608>

    Whatever the term is after call, match them :)



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3609>

    What is "4440" ? I would use a talkative const string for this, if this hard is really needed.



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3610>

    Why do you use capital letter here for "Editingfinished" and small letter for the "finished". According to the camel case rules, it should be: "editingFinished". However I am not sure, but I would use editFinished here.



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3611>

    editFailed ?



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3614>

    Why do we need apply* methods if they are called just once and they are intended to be private ? Wherever else would you like to use it ? 



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3612>

    Match the term after all whatever you choose. This is true for all the applies.



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3616>

    I understand the attica uses addNew* naming schema, but I will rename it in the new attica version simply for add*.
    
    I would propose to change it to "addGame".
    
    We are adding new game here anyway. :)



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3617>

    Naming schema change accordingly.



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3615>

    You forgot to emit the signal here as well :) Furthermore, I would use "addGameFinished".



player/lib/remotegame.cpp
<http://git.reviewboard.kde.org/r/101816/#comment3618>

    I would use addGameFailed.


- Laszlo


On July 2, 2011, 2:29 p.m., Shantanu Tushar Jha wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101816/
> -----------------------------------------------------------
> 
> (Updated July 2, 2011, 2:29 p.m.)
> 
> 
> Review request for Gluon.
> 
> 
> Summary
> -------
> 
> Category's job is to fetch list of categories from the server.
> NewGame takes a game name and a category, and then creates a new game on the server, returning the ID of newly created game.
> 
> 
> Diffs
> -----
> 
>   player/lib/CMakeLists.txt 53c0f0a 
>   player/lib/category.h PRE-CREATION 
>   player/lib/category.cpp PRE-CREATION 
>   player/lib/remotegame.h PRE-CREATION 
>   player/lib/remotegame.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/101816/diff
> 
> 
> Testing
> -------
> 
> Both classes function as expected when used.
> 
> 
> Thanks,
> 
> Shantanu Tushar
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/gluon/attachments/20110702/0628c71a/attachment-0001.htm 


More information about the Gluon mailing list