Hacer un gran negocio de == verdadero?

105

Hay un colega mío que escribe constantemente:

if (someBool == true)

¡Me saca de quicio! ¿Debo hacer un gran negocio o simplemente dejarlo caer?

JoelFan
fuente
12
Prefiero lo explícito if (some_flag == true)pero lo implícito if (is_something)o if (has_something). Tenga en cuenta los nombres de las variables.
fredoverflow
69
Recuerde a su colega que el tipo de someBool == truetambién es booleano, por lo que, según la misma lógica, debería serlo if ((someBool == true) == true).
Mike Seymour
2
@GSto: Supongo que lo sabes, pero en PHP puedes hacer eso para "lanzar" cualquier cosa a un bool y puede ser realmente útil.
zneak
2
@zneak O podrías ser más claro y usarlo $var = (bool) some_expression. Y en la mayoría de los casos, ni siquiera importará, ya que PHP hará las conversiones necesarias de forma dinámica.
waiwai933
44
compruebe siempre la constante primero, if (true == someBool), en caso de que haya escrito accidentalmente = en lugar de == [¡sí, estoy bromeando!]
Steven A. Lowe

Respuestas:

126

Es solo código redundante, no vida o muerte. Sin embargo....

Si sucede mucho, podría ser un problema con cómo someBoolse nombra. Un buen nombre puede contribuir en gran medida a eliminar la necesidad de==true

if(IsSomeCondition)

o

if(hasCondition)

o

if(somethingExists)

por ejemplo.

Robert Harvey
fuente
Esto me suena muy fiel. Se trata de claridad y el arte de nombrar, la sintaxis original no es tan mala, pero este es el camino correcto para un mejor código.
TJB
2
¡Golpéame! Sin un nombre apropiado, la equivalencia más sucinta no tiene ningún sentido.
Troy Hunt
44
He tenido que usar el someBool == truecódigo heredado varias veces para mayor claridad. Pero si escribo desde ceroif (isSomething)
nombro
Estoy de acuerdo, aunque nombrar resolvería esto, suponiendo que el nombre fuera SomeBool, podría significar cualquier cosa y ser de cualquier tipo (¿un entero igual a la cantidad de booleanos en una matriz tal vez?). Los booleanos necesitan algún tipo de verbo existencial, o siempre serán difíciles de leer por sí mismos.
Morgan Herlocker
Estoy de acuerdo, se trata de legibilidad. Si las variables se nombran bien, no las necesita. Si la expresión se lee mejor con ella, iría por "== verdadero", también es coherente si usa "== falso" en lugar de (lo feo) "if (! ())".
Ronny Brendel
71

Cuando veo someBool == true, no puedo evitar sentir que el programador no ha internalizado la idea de la evaluación , que es una deficiencia bastante fundamental.

Sin embargo, mi perspectiva es sesgada porque pasé varios veranos en la universidad enseñando programación a niños, quienes frecuentemente escribían expresiones como esta porque realmente no habían dominado el ejercicio mental de evaluar una expresión. Una vez que asimilaron el concepto, la redundancia se hizo evidente.

Para un programador profesional competente, este no es el caso. Probablemente sea solo un mal hábito que desarrollaron en sus primeros días de programación y nunca temblaron. Pero aún así me asustaría un poco si fuera lo primero que vi hacer a alguien en una entrevista.

Tim Goodman
fuente
No rápidamente atribuiría esto a la costumbre. He escuchado algunas cosas realmente impresionantes de la boca de los programadores profesionales. Por lo general, seguido poco después por uno de los grokkers, "¿cómo esta vez funciona?"
dash-tom-bang
12
Acuerde de todo corazón sobre la evaluación. En ocasiones me he preguntado: "¿Dónde se detiene?" if ((((x == true) == true) == true)! = false) // y así sucesivamente ...
yawmark
1
A veces escribía if (c == true) return true; else return false;, pero el 99% de las veces (el 1% está ahí, ya que nunca puedo estar seguro de que no me perdí algo), notaré inmediatamente y reemplazaré todo return c. Esperaré que los programadores más competentes hagan algo similar si desarrollaron el hábito temprano en su carrera. Lo que no esperaría es una respuesta wtf.
Lie Ryan
1
Oh chico, el arte de pensar. Literalmente me encontré con esto en nuestra base de código la semana pasada. if (!someCondition) { someCondition = false; }He visto algunas (er, muchas) redundancias, así como algunas imposibilidades en nuestro código, pero este fue tan simple pero tan irritante para pensar que alguien realmente lo escribió. Múltiples veces, incluso.
Anthony Pegram
1
Solo tenga en cuenta que he visto algunos casos de los if(x) x=true;cuales NO eran redundantes, sino más bien el equivalente de x=!!x;(normalizar x a 0/1)
jkerian
58

Eso también me vuelve loco, pero diría que les menciono la redundancia de manera constructiva y luego la dejo caer si no están de acuerdo.

Alternativamente, puede probar este enfoque:
Usted: ¿Puede comenzar a usar la siguiente convención de código para evaluar booleanos?

if (someBool==true)&&(true==true) {}

Ellos: ¿Por qué haríamos eso? La segunda mitad de esa declaración es redundante, siempre se evaluaría como verdadera.

Tú: Por George, tienes razón. Tonto de mí. Vayamos con una versión sin toda la redundancia entonces. ¿Qué tal si?

if (someBool) {}
JohnFx
fuente
66
Si, de acuerdo. Es una tontería, pero debes elegir tus peleas, y este código está haciendo lo que tu colega hará. Mencione en un no- "¿Qué demonios está mal contigo?" de alguna manera, luego suéltalo. Aunque si comienzan a tirar basura como "if (someBool! = True)" o "if (! SomeBool == true)" u otras convoluciones similares, esa podría ser una pelea que vale la pena elegir ...
BlairHippo
3
¿Cómo es (someBool == false) peor que si (someBool == true)?
FinnNk
55
true=trueno se compila, no se puede asignar a true;-)
fredoverflow
1
Me he acostumbrado a if(somebool == false)o !=, pero siempre contra falso y no verdadero. Lo encuentro redundante, pero dado que el estándar de codificación insiste en que if()parece una función llamar al espacio en blanco entre los parens me ayuda a leerlo. Por mi cuenta, un bool es un bool, pero if (somePointer)no vuela; Prefiero if (somePointer != NULL)ya que un puntero no es un bool.
dash-tom-bang
55
Se trata de legibilidad, no de ilógica o (micro) redundancia
Ronny Brendel
45

Creo que, si algo tan trivial es su mayor problema con sus compañeros de trabajo, debería considerarse bastante afortunado.

GrandmasterB
fuente
55
Bien dicho, es bueno luchar por la perfección, pero seguramente hay peces más grandes para freír
TJB
3
Creo que dices esto sobre cada problema que merece discusión.
Dave Van den Eynde
2
Es potencialmente indicativo de problemas mucho más grandes. Una pequeña mancha marrón en el techo de su garaje puede no parecer un gran problema, pero podría significar que tiene una fuga de agua importante.
Josh
42

Definitivamente deberías dejar este mal hábito. Suavemente...

Es fácil olvidar escribir los signos de doble igualdad, convirtiendo el código en:

if (someBool = true)

En C #, por ejemplo, esto solo generará una advertencia, no un error. Entonces, a menos que trate las advertencias como errores, el código se ejecutará, establezca la variable en verdadero y siempre ingrese la condición.

Guffa
fuente
66
Este no es un argumento relevante. Si estás trabajando en un idioma como ese, puedes mover el verdadero al otro lado. La pregunta es acerca de si incluir o no la verdad.
Cam
8
@Cam: Te estás perdiendo el punto. Lógica hacia atrás no estoy sugiriendo.
Guffa
15
@Cam: está dando un ejemplo del mundo real de cuándo esto puede ser un problema. Yo diría que esto es bastante relevante.
ChaosPandion
1
@Guffa Cam tiene mucha razón. Esta no es una razón para dejar de usar == (anyType) en bloques if.
Ronny Brendel
2
@Ronny: No, no puede suceder con ningún tipo (a menos que el idioma permita realmente cualquier tipo como condición). La declaración if (answer = 42) {}simplemente no se compila porque la expresión no es un bool.
Guffa
21

Estoy de acuerdo contigo, pero voy a jugar al abogado del diablo aquí:


Dependiendo del idioma y el nombre de la variable, x == verdadero es apropiado:

Considere la siguiente situación en un lenguaje con tipeo estático y coerción de tipos para tipos integrales:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Alguien que lea esta sección del código podría no darse cuenta de inmediato de que actionsAllowed es una variable booleana; también podría ser un número entero, que representa el número de acciones permitidas. Entonces, al agregar == verdadero, queda claro que x es un valor booleano, y no un número entero que se coacciona a un valor booleano:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}
Leva
fuente
13
legibilidad == GoodThing
Muad'Dib
55
if ((legibilidad == GoodThing) == verdadero) ...
JoelFan
1
bool isGoodThing = readibility? true: (codingStandards? true: (internalizationOfConcept? true: false));
johnc 19/10/10
17
Entonces cambie el nombre de la variable actionsAreAllowed.
Graeme Perrow el
99
Al escribir if (x) { ..., ya está afirmando que xes un valor booleano o convertible en un valor booleano. Lo que llamas es irrelevante.
Daniel Earwicker
15

¿Qué pasa con las boletas anulables?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
Steve Wellens
fuente
if (MyFlag.Value)
johnc
1
No todos los idiomas tienen bools anulables, y muchos de los que lo hacen aceptarán su segunda construcción.
zneak
1
@johnc: "if (MyFlag.Value)" realmente no puede hacer lo que quiere, ya que puede generar una excepción si MyFlag es nulo (que puede probar marcando MyFlag.HasValue).
Ludovic Chabant
44
Este es mi motivo favorito con bools anulables :)
Jarrod Dixon
3
bool? isValid = null; if (isValid ?? false);
skolima
11

Por lo general, no desea hacer un gran problema con las convenciones de codificación a menos que dicha convención de alguna manera impida el proyecto de manera significativa. He visto muchos argumentos acalorados sobre cosas tan pequeñas como regiones de código y guiones bajos.

Dicho esto, no veo ningún problema == truepara agregar a una declaración condicional. De hecho, tengo la costumbre de usar == falseen lugar de un signo de exclamación principal cuando hago pruebas para detectar condiciones negativas. Creo que es más legible.

Si hay una convención establecida, digo que la sigan a menos que haya una razón para cambiar. Sin embargo, realmente no vale la pena plantear un gran problema.

Casey
fuente
1
Dependiendo de su idioma, someValue podría no ser necesariamente el equivalente de verdadero incluso si se evalúa como verdadero. Por ejemplo, se (9 == True)evalúa como falso en Python y me imagino que es similar en C ++.
dash-tom-bang
regiones de código y guiones bajos principales me dan ganas de golpear a la gente en la cara.
MGOwen
11

Ack Soy ese chico La vergüenza, la vergüenza. Así es como aprendí, y así es como "formateo automático" en mi cabeza. La única vez que uso la sintaxis preferida de Joel es cuando la variable bool tiene un prefijo verbal como "es". Necesito el verbo, ya sea "es", "puede", "hizo", o de lo contrario necesito el == para proporcionar el verbo "igual". Puede que nunca rompa ese hábito, así que lo entenderé si no me dices 'hola' en la calle.

Scott Fletcher
fuente
77
No es algo malo El código que se lee como texto real es mucho mejor que el implícito foo. Mantenga ese hábito en aras de la legibilidad.
Ronny Brendel
11

recuérdame el "código de locura booleana", es así

if(someBool == true)
   otherBool = false;
else
   otherBool = true

En lugar de:

 otherBool = !someBool
Marcelo de Aguiar
fuente
Eso es gracioso, tuve que mantener un sistema que los tuviera desparramados por todas partes. Me volvió loco.
Tjaart
8

Personalmente, no me gusta la forma de decir "no" en lenguajes basados ​​en C. Ese pequeño signo de exclamación es demasiado fácil de pasar por alto.

Por eso lo escribo en su totalidad:

if (someCondition == false) {

Después de leer eso por un tiempo, también quiero simetría con

if (someCondition == true) {

Así que considérelo un artefacto de C usando en !lugar de not.

usuario1249
fuente
3
C ++ en realidad tiene el notoperador, y también C (una vez que incluye el encabezado estándar <iso646.h>). Si no quiere (o no puede) usar esta cabecera (o si le pegan con Java o C #), yo sugeriría poner un espacio después del signo de exclamación: if (! condition). Esto lo hace algo más visible.
Konrad Rudolph el
1
Yo hago Java notno es una opinión.
6

Depende del idioma, pero generalmente es una mala idea ...

En C, nunca hagas esto. Es demasiado fácil encontrar una situación en la que el valor que está probando no sea falso (distinto de cero), pero tampoco sea igual al valor único definido como "verdadero".

En Ruby, haga esto solo si está absolutamente seguro de que desea fallar en todo excepto en el booleano verdadero.

En C ++ y otros lenguajes estáticos con un tipo bool, es redundante y puede provocar errores de programación cuando escribe incorrectamente en =lugar de ==errores de promoción como se menciona en los comentarios.

AShelly
fuente
En realidad, en lenguajes donde el operador de asignación devuelve un valor ... como C ++ ... if (b == true) {no es solo redundante. También es un poco arriesgado, porque es posible que accidentalmente asignado truea b.
Stephen C
44
No solo es redundante en C ++, es peligroso. Si escribe if (b == true), y bno es un bool, las conversiones de tipo van por el camino equivocado. A booles un tipo integral que normalmente se promueve a un tipo integral apropiado con valor 1. Si escribe, digamos, int b(2); if (b == true)entonces se trueconvierte en un intvalor 1 para fines de la comparación, en lugar de bser coaccionado en tipo bool, lo que daría el resultado correcto.
David Thornley
@DavidThornley, active las advertencias en su compilador. Tratar las advertencias como errores es una mejor técnica de programación defensiva en lugar de evitarlas ==.
Abyx
5

¿Crees que es malo? Qué tal si:

if(someCondition) {
  return true;
} else {
  return false;
}
Sverre Rabbelier
fuente
2
Chico, cuántas veces he visto esto. Esto es un buen caso para una herramienta como ReSharper.
Trabajo
Sí, si contrata terrones, compre ReSharper.
Kirk Broadhurst el
4

yo prefiero

if (bVal)

o

if (!bVal)

también, pero me temo que mencionarlo molestaría a la gente, así que mi consejo es que lo olviden. ¡Lo siento!

grokus
fuente
44
Por el amor de todo lo que es santo, siempre que no lo sea if (!bNotVal) o if (bNotVal)incluso en primer lugar. Ugh negativos en los nombres hace que todo sea más difícil de leer.
dash-tom-bang
2
Conocí a un desarrollador que bool es IsNotConnected; if (isNotConnected == true) ... yuck
johnc
4

deberías decirle que lo está haciendo mal.

sus

if (true == someBool) {

}

si alguna vez olvida uno = está en grandes problemas en su estilo de escritura.

Nombre para mostrar
fuente
3

Qué tal si

if (x == "true")

¿POR QUÉ ES UNA CADENA?

Atfergs
fuente
Estoy trabajando en un código php heredado correctamente y ocasionalmente encuentro algo así if(preg_match('/title/', implode($_POST))){. PHP, dicho lo suficiente, necesito encontrar un mejor trabajo.
Keyo
44
sí, también veo si (x == "1"), pero eso suele hacer con un diseño de base de datos deficiente.
atfergs
He usado construcciones similares cuando xprovienen de la entrada del usuario (archivo de configuración o servicio web, por ejemplo). Sin embargo, generalmente permito otros valores de mejora, por lo que termina más comoif x.lower().strip() in ["true", "yes", "on", "1"]
eswald
3

En realidad, si es anulable, sería necesario probar x == verdadero. :)

Matt Sherman
fuente
3

¡Escribo un código así!

Aquí es por qué:

"if bla == true" se lee como una oración, mientras que "if bla" en muchos casos no. Simplemente suena mal, al LEER el código real.

Además, el compilador advierte sobre las asignaciones en los bloques if, por lo que realmente no hay peligro al usar == verdadero. (confundiéndolo con =)

¿También los tipos que no escriben "== verdadero", usan eso "! ()" Para "== falso"? Lo encuentro realmente feo. Y si usa "== falso", es muy consistente también usar "== verdadero", en lugar de tener dos formas distintas de verificar la verdad.

Ronny Brendel
fuente
3
Usted dice "si bla" no se lee como una oración ... eso significa que su variable no se nombra correctamente ... lo que está mal con esto: if (userHasRights) doSomething ()
JoelFan
"en muchos casos". Sí, tiene usted razón. Cambiar el nombre también está bien. Con "if (QWidget :: acceptDrops () == true)" no tiene la posibilidad de cambiar el nombre. tal vez sería bueno nombrarloAceptaDrops () ... Es demasiado complicado (y es imposible ser coherente usando esa regla de omisión en cualquier API), por lo que ser coherente con otros "== lo que sea" -ifs, Sugiero encarecidamente no omitirlo, por lo que no se "ve" diferente, por lo tanto, parece coherente.
Ronny Brendel
3

Recuerde que está trabajando como parte de un equipo, por lo que debe resolver estas cosas juntos. "Jugar bien con los demás" sigue siendo un rasgo de personalidad importante incluso después de la escuela primaria :)

cdkMoose
fuente
2

En general, omitirá el '== verdadero', pero no vale la pena ni siquiera un minuto para discutirlo a menos que lo incluya en los estándares de codificación de su equipo.

FinnNk
fuente
3
Además, si está en los estándares de codificación del equipo, realmente necesita reevaluar los estándares para deshacerse de trivias como esta.
JohnFx
¡Convenido! Por si acaso ...
FinnNk
2

Si bien estoy de acuerdo como desarrollador principalmente de C #, no puedo decir que este sea siempre el caso. Por ejemplo, en Javascript, el === realizará una fusión de tipos. Asumiendo var x = 3 entonces:

if(x) --> true

mientras

if (x === true) --> false

Supongo que es diferente a == ya que incluso en JS no usaría if (x == true) sino algo en lo que pensar.

Este tipo de toques en otro punto que ha surgido en mi oficina:

bool b = false;

En C #, bool b; sería suficiente e inicializaría b a falso . Sin embargo, es más explícito escribir la línea anterior y, de todos modos, el compilador debe extraerlo durante la optimización.

Así que supongo que mi punto es que no siempre es tan obvio lo que es y no es una buena práctica y mucho se reduce a la preferencia, así como a las características / peculiaridades del lenguaje.

statichippo
fuente
bool b;solo se inicializa en falso cuando bes un campo. Debe inicializar las variables locales explícitamente.
Matthew Flaschen
+1 de acuerdo. Es el mismo problema con otros lenguajes (scripting) también. Debe ser explícito si desea probar booleano trueo simplemente "verdadero". Por ejemplo, es decir, cualquier cadena no vacía se considera == truepero no === trueen algunos idiomas.
Martin Wickman
2

Ah sí, pero ¿y si la variable es anulable? (bool?)

Algunos lenguajes (C #) requerirán una conversión o comparación con 'verdadero'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}
Jared G
fuente
2

Los jóvenes conocen las reglas, pero los viejos conocen las excepciones;)

En el último C#caso, si está tratando con un null-able bool, entonces debe:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Si tristate no es un problema, generalmente no debería haber una razón para comparar algo con true/ True. Sin embargo, en Pythony en varios otros idiomas, como C/C++puede realizar una ifexpresión no bool. Estos lenguajes tienen reglas únicas para interpretar enteros, punteros, listas, etc. como verdaderos o falsos. En algún momento no quieres eso. Por ejemplo, en este fragmento de Python:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Aquí zdebería ser True, pero z2debería ser False. Ahora, un Clojurelenguaje se acerca a esto de otra manera: su andfunción no necesariamente se evalúa como a bool, pero la funciónif puede manejar eso.

Independientemente del idioma, cada vez que te encuentres comparando algo Trueo False, probablemente valga la pena comentarlo.

Trabajo
fuente
El primer problema proviene de una premisa falsa de la OMI mediante el uso de nombres de variables horribles. Suponga que x, y, z fueron nombrados notExceptButHasX, exceptNotButIsntY, doNotUnlessIsExceptZ? ¿Cómo eso hace legibilidad en su problema? Si x, y, z fueron nombrados algo así como "isEnabled", "isEffective", "hasProperty", entonces su declaración se convierte en isEnabled || isEffective || hasPropertyalgo mucho más legible que compararlo con trueo false.
Thomas
1

Tal codificación también me habría molestado antes. Aunque su identificador de ejemplo se llama "someBool", usar ese estilo de codificación inadvertidamente en una variable que no se garantizó que sea booleana podría tener un comportamiento involuntario. Si el valor de "someBool" no es exactamente "verdadero" o "falso", el resultado será falso.

Encontré un error muy sutil el año pasado causado por un estilo de codificación tan difícil de identificar porque los ojos de uno brillan sobre tales construcciones. Uno pensaría: "¿Cómo podría estar mal?" Lo mismo se aplica a expresiones tan bien entendidas como "(var)" o "(! Var)", que las lee o las codifica sin verificar su comportamiento.

Así que introduje un par de estándares de codificación para reducir la existencia de tales errores en la base de código y la probabilidad de que tales errores sutiles se cuelen accidentalmente en algún momento en el futuro.

  1. Todas las expresiones deben estar entre paréntesis según su intención.
  2. Todas las pruebas booleanas deben expresarse en negativo, como "suchBool! = False".

Al limpiar el código que no se ajusta al nuevo estilo, he identificado y corregido algunas instancias más de errores tan sutiles.

Huperniketes
fuente
1
Tener algún someBool capaz de ser algo diferente a VERDADERO / FALSO es una mala práctica de codificación.
AttackingHobo
@AttackingHobo, esa es una de las dificultades de no tener tipos booleanos en un idioma y / o no usar una clase para proporcionar el comportamiento exacto deseado.
Huperniketes
1

Tuve que usar esto todo el tiempo en ActionScript 2 (ciertamente es un lenguaje muerto), porque:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Así que casi siempre era mejor ser específico.

bburbank
fuente
1

Estoy de acuerdo. Es una construcción redundante, especialmente en lenguajes mecanografiados fuertes.

Para agregar otro mal uso de booleanos, he encontrado este tipo de construcción muchas veces en Javascript, (especialmente en algunas funciones de monstruos tipo espagueti, como en más de 100 líneas):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Parece que debido a la falta de una definición de tipo estricta en este lenguaje, algunos programadores prefieren no tener que perder el tiempo con los false|undefinedvalores.

Tomás Narros
fuente
1

Tengo un colega que tendrá un código como este:

if(something == true)

Y luego, para algún tipo de prueba / depuración, deseará no llamar a este bloque, por lo que lo cambiará a:

if(something == true && false)

Y luego ocasionalmente lo cambiará a:

if(false)

Lo peor es que este tipo de depuración se me ha pegado en ocasiones y es realmente malo para que otros desarrolladores lo lean.

ingh.am
fuente
0

Yo diría que la consistencia es el rey en una base de código. Entonces deberías usar el estilo, eso es principalmente usa en su organización. Intente que su estilo preferido forme parte de las pautas oficiales de codificación de la compañía. Si ya está en las pautas, solo sígala.

(Dicho esto, también realmente me molestaría, pero probablemente no lo suficiente como para hacer un gran problema).

driis
fuente
0

Prefiero no colocar el extra == verdadero, pero a veces lo incluyo accidentalmente y no lo noto. Es posible que la persona no se haya dado cuenta y los haya colocado accidentalmente. Vuelvo a leer mi código y a veces me doy cuenta de que coloqué el extra == verdadero, así que elimino ese == verdadero. A veces no me doy cuenta y agradecería a alguien que me dijera que lo coloqué de forma redundante.

sange
fuente
0

qué tal si:

int j = 1;
for (int i=1; i>=j; i++) ...

Sí, lo he visto.

Dave
fuente