TypeNameCheck
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
Comienza localizando la implementación de TypeNameCheck y cualquier prueba que cubra el patrón actual de nombres de tipos. Revisa cómo se validan los nombres, define después pruebas para las variantes solicitadas con guion bajo o guion, y confirma que los nombres válidos existentes sigan siendo aceptados. Se considerará terminado cuando la comprobación gestione los nombres de clase versionados indicados.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Argh - this one is going to be painful for me. Looks like the type name check enforces a pattern '^[A-Z][a-zA-Z0-9]*$'.
Is there any chance we can get an underscore or dash included with that?
The reasoning - for sony products, their API differs depending on the API's version. Example: setPowerStatus v1.0 has a parameter of boolean and the getPowerStatus v1.0 returns a boolean. However, setPowerStatus v1.2 has a parameter of string and the getPowerStatus v1.2 returns a string.
To handle this in a reasonable manner - I have a "PowerStatus_1_0" class and a "PowerStatus_1_2" class.
That's one example out of about 50 classes named this way (I have one class that has 5 different variations depending on the version).
With out an underscore (or dash) - I'd have to renamed stuff to "PowerStatusOneZero" and "PowerStatusOneTwo" or something screwy like that. Using namespaces to differentiate will also be an even bigger issue (alot of overlap between versions so naming something like 'v1-5.xxx" would be hard to understand when the api would be spread over different namespaces).
- Lenguaje dominante
- Java
- Estrellas
- 34
- Forks
- 24
- Merge medio
- 7 h 52 min
- PR fusionados (30 d)
- 10
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de openhab/static-code-analysis
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
openhab/static-code-analysis#578 ·
Los mantenedores suelen responder en 1 día
-
Upgrades for 1.0.0-SNAPSHOTAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
openhab/static-code-analysis#536 · 5 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Invalid instructions for mavenAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
openhab/static-code-analysis#450 ·
Los mantenedores suelen responder en 1 día
Todos los issues de openhab/static-code-analysis
Issues similares
-
Upgrade to Commons Codec 1.23.0Abiertostatus: team-only type: dependency-upgrade
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
spring-projects/spring-boot#52143 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area/frontend good first issue kind/cooldown
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
kestra-io/kestra#20704 · 1 comentario ·
Los mantenedores suelen responder en 1 día