[jitsi-dev] ice4j: PseudoTCP code style


#1

Hey Pawel

While looking at the ice4j code to comment on Carl's request, I noticed lots
of deviations from the standard Java coding style and the Jitsi adaptions.
Examples are the "I" prefix in the interface, multiple classes in one file,
the use of Hungarian notation, and Pascal-Cased method names.

Would you mind to clean that up?

Regards,
Ingo


#2

Hi,

Hey Pawel

While looking at the ice4j code to comment on Carl's request, I noticed
lots
of deviations from the standard Java coding style and the Jitsi adaptions.
Examples are the "I" prefix in the interface, multiple classes in one file,
the use of Hungarian notation, and Pascal-Cased method names.

Would you mind to clean that up?

Regards,
Ingo

Sure I'll fix that but I have a couple of questions.

That "I" in IPseudoTcpNotify class was because of the same name in
libjingle. I tried to keep the same names for all variables and thats why
there can be found variables like bConnect, nSent etc. I thought that it
may be easier to change anything in the protocol if some changes may be
added in libjingle version. Can I keep those Hungarian style names as they
are in PseudoTcpBase ?

I'll fix Pascal cases for all methods and "I" will be removed from
interface.

Regards classes in one file they are also only in PseudoTcpBase because I
thought that they don't make any sense to be used enywhere else. Some
enumerations next to those classes might be removed but I tried to keep the
code as much similiar to that one in libjingle, however I am not sure if
that makes sense. Will it be ok if I will make them nested classes of
PseudoTcpBase ? Or should I keep them as is, or put each one of them in as
separate file ?

Option enumeration will be now public and I'll place it in a separate file
as it should be used with setOption and getOption methods. However I need
to expose this functionality in target Socket class which we were talking
about in as separate thread on the list.

···

2012/8/17 Ingo Bauersachs <ingo@jitsi.org>

--
Regards, Paweł Domas


#3

Hey Pawel

While looking at the ice4j code to comment on Carl's request, I noticed
lots of deviations from the standard Java coding style and the Jitsi
adaptions. Examples are the "I" prefix in the interface, multiple
classes in one file, the use of Hungarian notation, and Pascal-Cased
method names.

Would you mind to clean that up?

Sure I'll fix that but I have a couple of questions.

That "I" in IPseudoTcpNotify class was because of the same name in
libjingle. I tried to keep the same names for all variables and thats
why there can be found variables like bConnect, nSent etc. I thought
that it may be easier to change anything in the protocol if some changes
may be added in libjingle version. Can I keep those Hungarian style
names as they are in PseudoTcpBase ?

Okay, I thought there was some kind of RFC for PseudoTCP and you just used
libjingle as a starting point. If Emil also agrees, you can keep the names
as in libjingle for only internally used stuff. But the public API must
conform to the Java standards.

I'll fix Pascal cases for all methods and "I" will be removed from

interface.

Okay, good.

Regards classes in one file they are also only in PseudoTcpBase because I
thought that they don't make any sense to be used enywhere else. Some
enumerations next to those classes might be removed but I tried to keep

the

code as much similiar to that one in libjingle, however I am not sure if

that

makes sense. Will it be ok if I will make them nested classes of
PseudoTcpBase ? Or should I keep them as is, or put each one of them in as
separate file ?

I see no reason to let them inside the same file. It is easier to navigate
and understand code if each class has its own file. Being similar to
libjingle doesn't really help in a case where you need to re-sync code with
libjingle.

Option enumeration will be now public and I'll place it in a separate file

as

it should be used with setOption and getOption methods. However I need to
expose this functionality in target Socket class which we were talking

about

in as separate thread on the list.

Whatever option that is, please export it through PseudoTcpSocket and not
through the Impl.

Regards,
Ingo

PS: Could you please reply with plain-text mails?

···

2012/8/17 Ingo Bauersachs <ingo@jitsi.org>


#4

Hey folks,

Apologies for the lag

Hey Pawel

While looking at the ice4j code to comment on Carl's request, I noticed
lots of deviations from the standard Java coding style and the Jitsi
adaptions. Examples are the "I" prefix in the interface, multiple
classes in one file, the use of Hungarian notation, and Pascal-Cased
method names.

Would you mind to clean that up?

Sure I'll fix that but I have a couple of questions.

That "I" in IPseudoTcpNotify class was because of the same name in
libjingle. I tried to keep the same names for all variables and thats
why there can be found variables like bConnect, nSent etc. I thought
that it may be easier to change anything in the protocol if some changes
may be added in libjingle version. Can I keep those Hungarian style
names as they are in PseudoTcpBase ?

Okay, I thought there was some kind of RFC for PseudoTCP and you just used
libjingle as a starting point. If Emil also agrees, you can keep the names
as in libjingle for only internally used stuff. But the public API must
conform to the Java standards.

Agreed.

I'll fix Pascal cases for all methods and "I" will be removed from

interface.

Okay, good.

Regards classes in one file they are also only in PseudoTcpBase because I
thought that they don't make any sense to be used enywhere else. Some
enumerations next to those classes might be removed but I tried to keep

the

code as much similiar to that one in libjingle, however I am not sure if

that

makes sense. Will it be ok if I will make them nested classes of
PseudoTcpBase ? Or should I keep them as is, or put each one of them in as
separate file ?

I see no reason to let them inside the same file. It is easier to navigate
and understand code if each class has its own file. Being similar to
libjingle doesn't really help in a case where you need to re-sync code with
libjingle.

Agreed.

Emil

···

On 19.08.12, 17:49, Ingo Bauersachs wrote:

2012/8/17 Ingo Bauersachs <ingo@jitsi.org>

Option enumeration will be now public and I'll place it in a separate file

as

it should be used with setOption and getOption methods. However I need to
expose this functionality in target Socket class which we were talking

about

in as separate thread on the list.

Whatever option that is, please export it through PseudoTcpSocket and not
through the Impl.

Regards,
Ingo

PS: Could you please reply with plain-text mails?