usar lenguaje codigo java methods naming-conventions

codigo - lenguaje java



¿Cuál es el método más engañoso en la API base de Java? (17)

Recientemente boolean Boolean.getBoolean(String name) convertir un literal de cadena en un boolean , cuando el método boolean Boolean.getBoolean(String name) salió de la ventana de autocompletar. También boolean Boolean.parseBoolean(String s) otro método ( boolean Boolean.parseBoolean(String s) ) inmediatamente después, lo que me llevó a buscar las diferencias entre estos dos, ya que ambos parecían hacer lo mismo.

Resulta que lo que realmente hace Boolean.getBoolean(String name) es comprobar si existe una propiedad del System (!) Del nombre de pila y si su valor es true . Creo que esto es muy engañoso, ya que definitivamente no espero que un método de Boolean haga una llamada a System.getProperty , y simplemente mirando la firma del método, seguro que se ve (al menos para mí) como debería ser. ser utilizado para analizar una String como un boolean . Claro, el javadoc lo dice claramente, pero todavía creo que el método tiene un nombre engañoso y no está en el lugar correcto. Otras envolturas de tipo primitivo, como Integer también tienen un método similar.

Además, no parece ser un método muy útil para pertenecer a la API base, ya que creo que no es muy común tener algo así como -Darg=true . Tal vez sea una buena pregunta para una entrevista de posición de Java: "¿Cuál es el resultado de Boolean.getBoolean("true") ?". Creo que un lugar más apropiado para esos métodos sería en la clase del System , por ejemplo, getPropertyAsBoolean ; pero de nuevo, sigo pensando que no es necesario tener estos métodos en la API base. Tendría sentido tenerlos en algo parecido a la clase Properties , donde es muy común hacer este tipo de conversiones.

¿Qué piensas de todo esto? Además, si hay otro método "incómodo" del que sea consciente, publíquelo.

NB Sé que puedo usar Boolean.valueOf o Boolean.parseBoolean para convertir un literal de cadena en boolean , pero solo estoy buscando discutir el diseño de la API.

¡Bien, System.setOut () establecerá el valor a un miembro final de System !!!!

Acabo de isInterrupted los métodos isInterrupted interrupted e interrupted de la clase Thread . De javadoc :

static boolean interrupted() // Tests whether the current thread has been interrupted. boolean isInterrupted() // Tests whether this thread has been interrupted.

El problema es que la interrupted realmente borra el estado interrumpido además de hacer la prueba, mientras que isInterrupted simplemente prueba el estado.

Acabo de obtener esta de here , con respecto a los métodos para add y remove de List (cuando se parametriza con Integer ). Por ejemplo:

List<Integer> l = new ArrayList<Integer>(); l.add(20); l.remove(20); // throws ArrayIndexOutOfBoundsException, because it will try to access index 20 l.remove(new Integer(20)); // this works

BigDecimal.setScale (int) un setter que devuelve un BigDecimal hmmm

El método URL equals () compara direcciones IP, utiliza una conexión de red y es una operación de bloqueo.

De los javadocs:

Dos hosts se consideran equivalentes si ambos nombres de host se pueden resolver en las mismas direcciones IP; de lo contrario, si el nombre de host no se puede resolver, los nombres de host deben ser iguales sin importar el caso; o ambos nombres de host igual a null.

Como la comparación de hosts requiere resolución de nombre, esta operación es una operación de bloqueo.

Nota: Se sabe que el comportamiento definido para iguales es inconsistente con el alojamiento virtual en HTTP.

Use URI en su lugar.

Estoy de acuerdo. Siempre me he sentido incómodo con esos métodos.

Incluso encontré un error en nuestra base de código que fue causado por alguien que usa Integer.getInteger () para analizar una cadena, sin darse cuenta de que estaba buscando la propiedad.

Desafortunadamente, por supuesto, no hay forma de que la API pueda ser eliminada, por razones de compatibilidad con versiones anteriores.

No estoy seguro si alguien todavía usa esto pero el mensaje de error de DocumentBuilder.parse() si algo sale mal es (¿casi?) Siempre "El contenido no está permitido en prolog". incluso si la verdadera razón fuera algo completamente diferente.

No lo archivaría en "Más incómodo", pero java.security.MessageDigest.getInstance () me dio cierta confusión.

Normalmente me utilizan para ver que un método "getInstance ()" devuelve Singleton.

Si un método es devolver una Nueva instancia, podría esperar ver un MessageDigestFactory.newInstance (), o al menos una newInstance () en la clase MessageDigest en lugar de su método getInstance ().

Ver: MessageDigest.getInstance()

Por lo que he probado, MessageDigest.getInstance () devuelve una Nueva Instancia, cada vez que se invoca.

Nunca entendí por qué la API JDBC comienza a contar constantemente con 1, mientras que el resto del universo Java (y C, C ++, C #, ...) comienza en 0. Esto aplica para números de columna, números de parámetros en declaraciones preparadas, etc.

Probablemente no sea el peor método, pero nunca me gustó este :

Supongamos que x es una lista conocida por contener solo cadenas. El siguiente código se puede usar para volcar la lista en una matriz recientemente asignada de Cadena:

String[] y = x.toArray(new String[0]);

Pasar una matriz String del tamaño 0 al método me parece loco y poco intuitivo.

Un problema bien conocido de la clase Calendar es que los meses están numerados de 0 a 11 en lugar de 1 a 12. Es muy fácil cometer un error como este:

Calendar cal = Calendar.getInstance(); // Set date to August 18, 2009? WRONG! Sets the date to September 18, 2009! cal.set(2009, 8, 18);

La forma correcta de hacerlo es mediante el uso de constantes para los meses:

cal.set(2009, Calendar.AUGUST, 18);

Pero el método hace que sea demasiado fácil cometer el error de usar los números de mes normales del 1 al 12.

Considero esto como un error en el diseño de la clase Calendar.

Una de mis preocupaciones favoritas con Java es el hecho de que una falla en Integer.parseInt ("SomeString") simplemente indica que hubo un error de análisis, al no decirnos qué era "SomeString". Debido a esto, a veces es necesario realizar muchas depuraciones para descubrir cuál era la cadena. Si el mensaje de error incluye la cadena errónea, rastrear el problema sería mucho más rápido.

mi problema es con el método de subcadena de String; cada vez que lo uso tengo que escribir la palabra "hamburger" y "hamburger" .substring (4,8) = "urge" para recordar cómo usarlo correctamente

InputStream.read(byte[])

No llena la matriz; en su lugar, lee un número arbitrario de bytes y devuelve ese número. Tienes que repetir. Desagradable, porque funciona correctamente para matrices pequeñas la mayor parte del tiempo. No creo que nadie lo haga bien la primera vez que lo usan.

java.util.Date.getDate() devolvió un número, 1-31. getDayOfMonth() es la forma más precisa de explicarlo, mientras que normalmente intentabas recordar getTime() .

No puedo esperar a que Joda Time se haga cargo.

String.getBytes()

a menudo es la causa de muchos problemas de codificación de caracteres estúpidos en aplicaciones porque usa la codificación de caracteres de la plataforma subyacente.