rails-devel

[Rails-devel] Code duplication (in 1837 and in general)

[Stefan F. <ste...@we...>]

Martin,
could you please avoid to duplicate code and classes that differentiate 
only a single parameter? Current example are those classes related to 
Folding and Merging into the three national railways of 1837.

*** General remark for all contributors
(so currently mainly Martin and Alexander):

 From my experience now, one thing that makes refactoring and rewriting 
of Rails somehow difficult and tedious is code duplication in the past.

To some degree this is always unavoidable, as this is the easiest way to 
ensure that code can be changed without breaking existing code.

However later on it is difficult to merge the code again as you have to 
check carefully if the code is only copied or if the code was changed 
afterwards.

So please think double, before you copy code from existing classes or if 
there other ways to ensure your goal.

I know it is especially difficult for the Round classes as they are 
combining all kind of functionality. I will break those classes into 
smaller bits as soon as Rails 2.0 is out of its door, however the more 
code in existing Round classes exists, it will get more work to break 
them up.

Feel free to comment.

Stefan

Re: [Rails-devel] Code duplication (in 1837 and in general)

[Michael A. <out...@gm...>]

That makes a lot of sense to me.  One of the reason I haven't pushed the
Parliament Round stuff back up yet was because what I originally wrote had
a lot of "almost duplicate" code that I wanted to get rid of.

Mike


On Thu, Aug 21, 2014 at 10:34 AM, Stefan Frey <ste...@we...> wrote:

> Martin,
> could you please avoid to duplicate code and classes that differentiate
> only a single parameter? Current example are those classes related to
> Folding and Merging into the three national railways of 1837.
>
> *** General remark for all contributors
> (so currently mainly Martin and Alexander):
>
>  From my experience now, one thing that makes refactoring and rewriting
> of Rails somehow difficult and tedious is code duplication in the past.
>
> To some degree this is always unavoidable, as this is the easiest way to
> ensure that code can be changed without breaking existing code.
>
> However later on it is difficult to merge the code again as you have to
> check carefully if the code is only copied or if the code was changed
> afterwards.
>
> So please think double, before you copy code from existing classes or if
> there other ways to ensure your goal.
>
> I know it is especially difficult for the Round classes as they are
> combining all kind of functionality. I will break those classes into
> smaller bits as soon as Rails 2.0 is out of its door, however the more
> code in existing Round classes exists, it will get more work to break
> them up.
>
> Feel free to comment.
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Code duplication (in 1837 and in general)

[Dr. M. B. <dr....@t-...>]

Stefan,
let me answer directly:

The current code is far from finished, thats one reason why its not yet 
in rails_2_develop. Its pushed to the current branch with 2 goals: To be 
able to work on different machines and to get feedback on ealry ideas.

Thanks for the feedback though.

I agree with you that the goal should be to have as least code as 
possible and one duplicated without real purpose.

The (or rather my ) design goal for the formation round is to have one 
"NationalFormationRound"-Class that can work for (1835,1837,1856(?), 
18OE, and maybe more). I am way afar from that goal in the moment but 
would like to be able to test certain game mechanics after 
implementation, thats the reason why i copied the code the way it is 
currently.

Regards,
Martin



Am 21.08.14 um 16:34 schrieb Stefan Frey:
> Martin,
> could you please avoid to duplicate code and classes that differentiate
> only a single parameter? Current example are those classes related to
> Folding and Merging into the three national railways of 1837.
>
> *** General remark for all contributors
> (so currently mainly Martin and Alexander):
>
>   From my experience now, one thing that makes refactoring and rewriting
> of Rails somehow difficult and tedious is code duplication in the past.
>
> To some degree this is always unavoidable, as this is the easiest way to
> ensure that code can be changed without breaking existing code.
>
> However later on it is difficult to merge the code again as you have to
> check carefully if the code is only copied or if the code was changed
> afterwards.
>
> So please think double, before you copy code from existing classes or if
> there other ways to ensure your goal.
>
> I know it is especially difficult for the Round classes as they are
> combining all kind of functionality. I will break those classes into
> smaller bits as soon as Rails 2.0 is out of its door, however the more
> code in existing Round classes exists, it will get more work to break
> them up.
>
> Feel free to comment.
>
> Stefan
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Code duplication (in 1837 and in general)

[Stefan F. <ste...@we...>]

Martin:
No issue, due to your questions I was looking into your branch and 
realized that problem. I admit that happened in 1880 as well, but there 
are other places and there have been many occasions in Rails before.

So most likely you work differently than me, as soon as I realize that I 
start copying code, I begin to think about factoring things out.

Keep another thing in mind: You will not be able to load game files that 
have changed class names for actions. So if you want to keep save files 
working you are stuck with existing action class names.

This will hold true until we get rid of the Java serialization process 
and even then it will take some work to ensure backward compatibility.

Stefan


On 08/21/2014 05:23 PM, Dr. Martin Brumm wrote:
> Stefan,
> let me answer directly:
>
> The current code is far from finished, thats one reason why its not yet
> in rails_2_develop. Its pushed to the current branch with 2 goals: To be
> able to work on different machines and to get feedback on ealry ideas.
>
> Thanks for the feedback though.
>
> I agree with you that the goal should be to have as least code as
> possible and one duplicated without real purpose.
>
> The (or rather my ) design goal for the formation round is to have one
> "NationalFormationRound"-Class that can work for (1835,1837,1856(?),
> 18OE, and maybe more). I am way afar from that goal in the moment but
> would like to be able to test certain game mechanics after
> implementation, thats the reason why i copied the code the way it is
> currently.
>
> Regards,
> Martin
>
>
>
> Am 21.08.14 um 16:34 schrieb Stefan Frey:
>> Martin,
>> could you please avoid to duplicate code and classes that differentiate
>> only a single parameter? Current example are those classes related to
>> Folding and Merging into the three national railways of 1837.
>>
>> *** General remark for all contributors
>> (so currently mainly Martin and Alexander):
>>
>>    From my experience now, one thing that makes refactoring and rewriting
>> of Rails somehow difficult and tedious is code duplication in the past.
>>
>> To some degree this is always unavoidable, as this is the easiest way to
>> ensure that code can be changed without breaking existing code.
>>
>> However later on it is difficult to merge the code again as you have to
>> check carefully if the code is only copied or if the code was changed
>> afterwards.
>>
>> So please think double, before you copy code from existing classes or if
>> there other ways to ensure your goal.
>>
>> I know it is especially difficult for the Round classes as they are
>> combining all kind of functionality. I will break those classes into
>> smaller bits as soon as Rails 2.0 is out of its door, however the more
>> code in existing Round classes exists, it will get more work to break
>> them up.
>>
>> Feel free to comment.
>>
>> Stefan
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>